浏览器安全机制

同源策略

同源策略会隔离不同源的 DOM、页面数据 和 网络通信，进而实现 Web 页面的 安全性。

同源策略保证了 安全 和 自由 ：

• 默认页面中可以引用任意第三方资源，然后又引入 CSP 策略来加以限制；
• 默认 XMLHttpRequest 和 fetch 不能跨站请求资源，然后又引入 CORS 策略来支持其跨域；
• 不同源的 DOM 是不能相互操纵的，因此浏览器中又实现了 跨文档消息机制，让其比较安全的通信。

xss

xss 全称 Cross Site Scripting，即 跨站脚本。xss 攻击是指黑客往 html 文件中 或 dom 中注入 恶意脚本，从而在用户浏览页面时利用该脚本实现攻击。

恶意脚本能力

• 窃取 cookie。通过 document.cookie 获取 cookie 信息，然后通过 XMLHttpRequest 或 fetch 加上 CORS 功能将数据发送给 黑客服务器。
• 监听用户行为。通过注册 addEventListener 接口监听键盘事件，比如获取信用卡等信息。
• 修改 DOM 伪造登录窗口。用来欺骗用户输入账号密码等信息。
• 生成浮窗广告。影响使用。

攻击方式

存储型 xss

场景：

黑客通过网页上的评论功能输入一段 script 标签包裹的恶意 js，如果前后端都没有做好过滤处理的话，这段恶意 js 储存到了数据库中，在其他人打开这个页面加载到这条评论时，浏览器并不知道这是条恶意代码，解析到 script 标签后直接执行了。这就是存储性 xss 攻击。

特点：恶意 js 代码会经过数据库储存。

反射型 xss

场景：

恶意脚本作为网络请求的一部分，比如有一个网址后面带有参数 ?id=123，然后服务器直接返回给浏览器显示到 html 上。

http://baidu.com?id=123

这个 url 参数经过 服务器 后，直接返回给 浏览器 页面上解析显示，没有做任何处理；

此时如果将参数值 换成 一段恶意的 js 代码后，打开网页后就会直接解析执行这段恶意代码从而拿到用户的敏感信息。

http://baidu.com?id=<script>alert('反射型xss')</script>

特点：服务器并没有储存这段恶意代码，用户被诱导点击链接后即遭受攻击。

基于 DOM 的 xss

场景：

基于 dom 的 xss 攻击，也称基于文档型 xss 攻击，它并不会经过服务器，而是作为中间人的角色，在数据传输过程中劫持到网络数据包，然后修改里面的 html 文档。

特点：通常通过 WIFI 路由劫持 和 本地恶意软件劫持 等。

总结

XSS 攻击是指浏览器中 执行恶意脚本，然后拿到用户的信息进行操作。主要分为 存储型、反射型 和 文档型。

防范措施主要包括 不要信任用户的输入、利用 CSP 和 Cookie 的 HttpOnly 属性。

防范 xss 攻击

• 服务器对输入脚本进行 过滤 或 转码，过滤 、转码 关键符号和 关键词。可参照 xss.js
• 利用 CSP 内容安全策略，核心就是 服务器决定浏览器加载哪些资源
  • 限制加载其他域下资源文件，这样即使黑客插入了一段 js 文件也无法被加载。
  • 禁止向第三方域 提交数据，这样用户数据不会外泄。
  • 禁止执行 内联脚本 和 未授权的脚本。
  • csp 提供上报机制，可以帮助我们尽快发现 xss 攻击，以便尽快修复。
• 利用 HttpOnly 属性。很多 xss 攻击都是盗取 cookie，因此可以通过使用 HttpOnly 属性来保护 cookie 安全，即 cookie 只能通过 http 请求过程中携带，不能通过 document.cookie 来获取。

CSRF

什么是 CSRF 攻击？

CSRF （Cross-site request forgery），即跨站请求仿造，指的是黑客诱导用户点击链接，打开黑客的网站，然后黑客利用用户目前的登录状态发起跨站请求。

CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。

举例，在某个论坛点击了黑客精心挑选的小姐姐图片，你点击后，进入了一个新的页面，那可能就是被黑客攻击了。

怎么被攻击了呢？这点击发生了什么？可能会发生三件事，列举如：

• 自动发起 GET 请求

  黑客网页中可能有一段这样的代码

  <img src="https://xxx.com/info?user=hhh&count=100"></img>

  利用 img 标签，进入网页后自动发送 GET 请求，值得注意的是，这个请求会自动带上关于 xxx.com 的 cookie 信息（这里假定你已经在 xxx.com 中登陆过）。

  假如服务端没有相应的验证机制，他可能认为发请求的是一个正常的用户，因为携带了相应的 cookie ，然后进行相应的各种操作，可以是转账汇款以及其他恶意操作。

• 自动发起 POST 请求。

  黑客可能自己填了一个表单，写了一段自动提交的脚本。

  <form id='hacker-form' action="https://xxx.com/info" method="POST">
    <input type="hidden" name="user" value="hhh" />
    <input type="hidden" name="count" value="100" />
  </form>
  <script>document.getElementById('hacker-form').submit();</script>

  同样会携带相应的用户 cookie 信息，让服务器误认为是一个正常的用户在操作，让各种恶意的操作变为可能。

• 引诱用户点击链接发起 GET 请求。

  在黑客网站上，可能会放上一个链接，驱使你点击：

  <a href="https://xxx/info?user=hhh&count=100" taget="_blank">点击进入修仙世界</a>

  点击后，自动发送 get 请求，接下来和自动发 get 请求部分同理。

这就是 CSRF 攻击的原理。和 XSS 攻击对比，CSRF 攻击并不需要将恶意代码注入用户当前页面的 html 文档中，而是跳转到新的页面，利用 服务器的验证漏洞 和用户之前的 登录状态 来模拟用户进行操作。

CSRF 攻击特点

• 目标站点一定要有 CSRF 漏洞
• 用户登录过目标站点，并且保持 登录状态
• 用户需要打开一个第三方站点，可以是 黑客的站点，也可以是一些论坛

防范 CSRF

CSRF 攻击的形成主要是由于 服务器有漏洞导致，对此主要对 服务器 做防护处理：

• 充分利用 cookie 的 SameSite 属性，选项通常设置有 Strict、Lax 和 None：
  • Strict 最为严格。如果 SameSite 的值是 Strict，那么浏览器会完全禁止第三方 Cookie。简言之，如果你从极客时间的页面中访问 InfoQ 的资源，而 InfoQ 的某些 Cookie 设置了 SameSite = Strict 的话，那么这些 Cookie 是不会被发送到 InfoQ 的服务器上的。只有你从 InfoQ 的站点去请求 InfoQ 的资源时，才会带上这些 Cookie。
  • Lax 相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
  • 而如果使用 None 的话，在任何情况下都会发送 Cookie 数据。
• 验证请求的来源站点，通过 http 请求头中的 Referer 和 Origin 属性，服务器端验证请求来源站点
  • Referer 是 请求来源的 URL（包含具体 URL 路径）
  • Origin 是请求来源的 域名（不包含具体 URL 路径）
  • 两者区别在于 Origin 只包含 域名，服务器会优先判断 Origin，请求头中没有的话再看情况判断 Referer
  • 但是这两者都是可以伪造的，通过 Ajax 中自定义请求头即可，安全性略差
• CSRF Token，服务器给浏览器生成一段 字符串 ，植入到返回的 页面中，在浏览器发起转账请求时带上 CSRF Token，服务器验证是否合法，如果请求是从第三方站点发出，则无法获取 CSRF Token。

总结

CSRF（Cross-site request forgery）即跨站请求伪造，指的是黑客诱导用户点击链接，打开黑客网站，然后黑客利用用户目前的登录状态发起跨站请求。

CSRF 攻击一般会有三种方式：

• 自动 GET 请求
• 自动 POST 请求
• 诱导点击发送 GET 请求

防范措施：利用 cookie 的 SameSite 属性、验证来源站点的 Referer 、 Origin 和 CSRF Token。