同源策略
同源的判断条件
相同的http协议，同一个域名，同一个端口
产生原因
为了阻止恶意程序获取用户重要信息
作用
不同源
- 阻止不同域名之间获取用户数据（cookie，locaStroage）
- 阻止不同域名之间获取dom信息
- 阻止不同域名之间使用 XMLHTTPRequest 发送数据给恶意服务器。
同源
- 可以相互访问和修改同源页面的dom
- 可以获取同源的 cookie locastroage等信息
- 同源策略限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点。
不同域名之间通讯的口子（绝对的安全违背web世界开放的初衷，并且开发上也有一些不便）
跨文档消息通讯
- 通过 postMessage api 获取不同域名间页面的dom信息
跨域资源共享
- 通过服务器端配置了 CORS（跨域资源请求策略）的 XMLHTTPRequest获取第三方资源
- CORS
页面可以嵌入第三方资源
- 通过script, link,img,video等标签获取第三方资源
- CSP（内容安全策略）
XSS攻击（Cross Site Scripting）跨站脚本攻击
概念： 黑客往html或者dom中注入恶意脚本，在用户访问该网站时，恶意脚本被执行，获取用户的信息。（当恶意脚本被注入，由于浏览器无法分辨恶意脚本是该网站本来就有的内容，所以恶意脚本拥有所有脚本能用的权限。）
危害
- 可以窃取用户cookie
- 可以监听用户行为（使用addEventListen api）
- 可以修改页面dom内容 伪造登录窗口从而获取用户重要信息
- 可以生成浮窗广告
攻击类型共同点
- 通过往浏览器页面出入javascrip脚本，然后在通过恶意脚本发送用户信息给黑客服务器。
xss攻击种类
-
服务端安全漏洞
-
存储型xss攻击
- 例子：利用服务器对用户输入的校验漏洞 存储一段 script脚本 到数据库，其他用户访问 该黑客用户的基本信息时，会执行数据库存储的恶意脚本，从而获取 其他用户信息
-
反射型攻击
- 例子：当用户在打开一个 带有get请求参数的网站，并且请求参数会被服务器重新返回给浏览器端使用。这是黑客可以将请求参数的 值设置为一段javascript脚本。当用户点击了恶意连接就会执行该脚本，从而回去用户数据
-
储存型xss攻击和反射型xss攻击是需要经过web服务端处理的
-
-
前端安全漏洞
-
dom型xss攻击都是在浏览器端完成的所以属于 前端安全漏洞。
-
基于DOM的xss攻击
- 它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。
-
解决问题手段
-
理论
- 阻止xss攻击方式是： 阻止恶意脚本注入浏览器 和 阻止脚本发送用户信息给黑客的服务器
-
实践手段
-
服务器对输入脚本进行过滤或者转码
- 如
- 处理的攻击类型是：存储型攻击
-
充分利用csp
- 由服务器来决定浏览器可以去请求哪些域名下的资源
- 处理的攻击类型是：页面嵌入第三方（恶意资源脚本）的问题
-
使用 HttpOnly 属性设置cookie
- 处理的攻击类型：针对恶意脚本获取用户cookie的攻击
-
CSRF攻击（跨站请求伪造）
攻击方式
- 引诱用户在登录状态下，点击黑客连接，用户点击之后，利用用户登录信息伪造get post请求（转账接口）转走用户虚拟货币。
防御方式
- 在响应信息带有 set-cookie的 响应头中添加 SameSite 响应头。
跨域资源共享 CORS
作用
- 可以通过xmlHttpRequest请求第三方资源
类别
-
请求种类
-
简单请求
-
请求方（浏览器端）
- 请求端在发送简单请求时，浏览器会自动添加origin 请求头信息（方便服务器判断是否为可跨域名单中）。
-
响应方（服务器端）
-
access-control-allow-origin
- 这个响应头信息提供了可以跨域请求资源的 域名有哪些。可以是 * 号，那就代表任何域名都能访问该资源。
-
access-control-allow-credentials
- 是一个布尔值。默认是情况下是不需要发送cookie给服务端，设置为true则代表cookie可以包含在请求头之中。（这里还涉及到浏览器端 xmlHttpRequest实例 的 withCredentials属性，只有当这个属性为true并且 符合同源策略，浏览器才会真正发送cookie）
-
access-control-allow-headers
- core请求时XMLHttpRequest实例对象的getResponseHeader()方法只能拿到六个基本字段，如何想获取其他字段就必须 在这个响应头中列出。
-
-
-
预检请求
-
特点
- 在发送真正的请求之前，浏览器会先发送一个 预检请求，获取服务器关于跨域请求的信息。
-
预检
-
请求头
- 预检是使用 options方法发送的 ，请求头会带上origin，要特定额外设置的请求头，真正请求要使用的方法
-
响应头
-
Access-Control-Allow-Methods
-
Access-Control-Allow-Origin
-
Access-Control-Allow-Headers
-
Access-Control-Allow-Credentials
-
Access-Control-Max-Age
- 这个表示这次预检的有效时间。在有效时间之内下次 预检请求不需要 预检！
-
-
-
-
-
区分请求类型的规则
- 1.使用head，get，post中的一种请求方法。
- 2.http请求头信息不超出以下几种字段：accept, accept-language,content-language,last-event-ID,content-tyep: application/x-www-form-urlencoded, multipart/form-data, text/plain
-
不同之处
- 非简单请求需要 预检 ，也就是说在发送请求之前，要先发送一条 “预检” 请求，从而知道服务器支持哪些请求方法，能跨域请求的域名有哪些，是否可以添加额外请求头。
-
为什么会有类别的区分
- 简单请求就是表单form（表单是可以跨源请求的）可以发出的请求 预检请求就是需要自定义一些属性才能实现的。 因为简单请求不通过ajax就可以去跨源请求（from表单）所以做一次预检没有必要 反而会浪费计算 预检请求的开销。 （预检 CORS-preflight）
withCredentials
- xhr.withCredentials = true; 只有ajax实例的这个属性设置为true时浏览器才会在请求头中带上cookie。 Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。
与jsonP的区别
- 优点：jsonp兼容性好
- 缺点：jsonp 只支持get请求
core支持所有类型的http请求，但兼容性没那么好。
CSP（内容安全策略）
目的
- 减少和报告xss攻击
作用
-
例子
- 比如一个可以上传图片和显示图片的页面，应该允许图片显示来自任何地方，但是限制表单的action属性只可以赋值为制定的断点。 这样经过恰当设计的内容安全策略应该可以有效保护页面免受跨站脚本攻击
使用
-
添加Content-security-policy响应头到一个页面（html文件），并配置相应的值。用于控制用户代理（浏览器等）可以为该页面获取哪些资源。
-
实例
-
content-security-policy: default-src 'self'
- 一个网站管理者想要所有内容均来自站点的同一个源 (不包括其子域名)
-
content-security-policy: default-src 'self' *.trusted.com
- 一个网站管理者允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)
-
content-security-policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscript.example.com
- 一个网站管理者允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得)，所有脚本必须从特定主机服务器获取可信的代码.
-
Content-Security-Policy: default-src onlinebanking.jumbobank.com
- 该服务器仅允许通过HTTPS方式并仅从onlinebanking.jumbobank.com域名来访问文档。
-
跨域的文档通信
跨域发送信息使用 window.postMessage(string message, origin). 接收两个参数 第一个参数是要发送的信息（只能是字符串）。第二个是要发送到哪个地址
条件
- 是一个页面通过window.open打开了另外一个页面
