HTTP相关 三.网络安全（XSS，CROS）

[helingjuan]

HTTP相关 三.网络安全（XSS，CROS）

3.1 什么是跨域？

3.2 CROS预请求验证

3.3 XSS 和CROS跨域问题

3.4. 什么是内容安全策略（CSP：Content-Security-Policy）？

3.5 jsonp 的作用

3.6 fetch发送2次请求的原因？

3.7 Cookie如何防范XSS的攻击

XSS攻击

什么是XSS攻击

XSS 就是Cross-Site Scripting（跨站脚本攻击），就是一种代码注入攻击
就是页面被注入了恶意的代码
攻击通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行，利用这些恶意脚本，攻击者可获取用户的明个信息如Cookie、SessionId等，进而危害数据安全

XSS本质：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。而由于直接在用户的终端执行，恶意代码能够直接获取用户信息，或者利用这些信息冒充用户向网站发起攻击者定义的请求。

提出疑问

判断一下，下面这两种说法是否正确：

1. XSS防范是后端的责任，后端应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作？
2. 所有要插入页面上的数据，都要通过一个明个字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入页面中；

发生场景

1. 根据URL参数决定搜索关键字内容，在关键字里注入脚本"><script>alert('XSS')</script>",浏览器无法分辨出这个关键字是恶意代码，因而执行了脚本，然后就会弹出alert

解决方法：escapeHTML()将字符进行转义，这样恶意代码就不会被浏览器执行，且搜索词能完美的在页面显示出来

原理：

• 通常页面中包含用户输入内容都在固定的容器或者属性内，以文本的形式展示
• 攻击者利用这些页面的用户输入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代码片段
• 攻击者通过在目标网站上注入脚本，使之在用户的浏览器上允许，从而引发潜在风险
• 通过HTML转义，可以防止XSS攻击

2. 特殊的HTMl属性、JavaScript API
   javascript:alert('XSS')，虽然不会立刻弹出XSS，但是这个会解析成点击a标签，就弹出XSS

解决方法： 白名单
对应链接跳转，如<a href="xxx" />或location.href="xxx"时，要检验其内容，根据项目情况进行过滤，禁止“javascript:”链接，非法scheme等

3. 根据上下文采用不同的转义规则

插入JSON的地方，不能使用escapeHTML()，因为转义后，JSON格式会被破坏

注意:

• HTML转义非常复杂，在不同的情况下药采用不同的转义规则，如果采用了错误的转义规则，很有可能会埋下XSS隐患
• 应当尽量避免自己写转义库，而应当采用成熟的、业界通用的转义库

总结：XSS注入的方法

• 在HTML中内嵌的文本中，恶意内容以script标签形成注入；
• 在内联的JavaScript中，拼接的数据突破了原本的限制（字符串、变量、方法名等）；
• 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签；
• 在标签的href、src等属性中，包含javascript:等可执行代码
• 在onload、onerror、onclick等事件中，注入不受控制代码
• 在style属性和标签中，包含类似background-image:url("javascript:...")的代码（新版本浏览器已经可以防范）
• 在style属性和标签中，包含类似expression(...)的css表达式代码（新版本浏览器已经可以防范）

用户可以通过哪种方式注入恶意脚本？

• 用户的UGC信息
• 来自第三方的链接
• URL参数
• POST参数
• Referer（可能来自不可信的来源）
• Cookie（可能来自其他子域注入）

XSS分类

根据攻击来源，可以分成3类：

• 存储型
• 反射型
• DOM型

存储型

恶意代码存在数据库里
常见于带有用户保存数据的网站功能，如论坛发帖，商品评论，用户私信等。

反射型

恶意代码存在URL里
常见于通过URL传递参数的功能，如网站搜索、跳转等

DOM型

网站前端的JavaScript代码本身不够严谨，把不可信的代码当作代码执行了

在使用.innerHTML,.outerHTML,document.write()要特别小心，不要把不可信的数据作为HTML插到页面上，而应该尽量使用.textContent,.setAttribute()

和上面两种的XSS的区别：DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JavaScript自身的安全漏洞；其他的属于服务端的安全漏洞

XSS攻击的预防

• 输入过滤
  可以在某些情况下解决特定的XSS问题，但会引起很大的不确定性和乱码问题，应该避免用此类方法
• 纯前端渲染，把代码和数据分隔开
• 对HTML做充分转义
• CSP(Content Security Policy)
  CSP的作用：
  • 禁止加载外域代码，防止复杂的攻击逻辑
  • 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域
  • 禁止内联脚本执行
  • 禁止未授权的脚本执行
  • 合理使用上报可以及时发现XSS，利用尽快修复问题
• 输入内容长度控制
• HTTP-only Cookie
• 验证码

XSS的检测

• 使用通用XSS攻击字符串手动检测XSS漏洞
• 使用扫描工具自动检测XSS漏洞

回答疑问

判断一下，下面这两种说法是否正确：

1. XSS防范是后端的责任，后端应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作？

不对，因为DOM型XSS攻击不发生在后端，是前端的责任。防范XSS是需要前后端共同参与的系统工程；并且，转义应该在输入HTML时进行，而不是在提交用户提交的时候

2. 所有要插入页面上的数据，都要通过一个明个字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入页面中；

不对，因为不同的上下文，所需要的的转义规则不一致，乱用反而更容易制造XSS攻击

CSRF攻击

什么是CSRF攻击？

CSRF （Cross-site request forgery）跨站请求伪造
攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对呗攻击的网站执行某项操作的目的

攻击场景

• 受害者登录a.com,并保留登录凭证
• 攻击者引诱受害者访问b.com
• b.com向a.com发送了一个请求，浏览器会默认携带a.com的Cookie
• a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
• a.com以受害者的名义执行操作
• 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作

攻击类型

• GET类型的CSRF， 发起GET请求
• POST类型的CSRF，使用一个自动提交的表单，访问该页面时，表单会自动提交
• 链接类型的CSRF，用户点击才会触发，通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招

CSRF的特点

• 一般是跨域的请求，可以用各种方式：图片URL、超链接、CORS、Form表单等
• 攻击利用受害者在被攻击完整的登录凭证，冒充受害者提交操作，而不是直接窃取数据
• 整个过程，攻击并不能获取到受害者的登录凭证，只能“冒用”

防护策略

1. 阻止不明外域的访问
   • 同源检测
   • Samesite Cookie
2. 提交时要求附加本域才能获取的信息
   • CSRF Token
   • 双重Cookie验证

同源检测（CROS）

Samesite Cookie属性

CSRF Token

要求所有用户请求都要携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF攻击

流程：

1. 将CSRF Token输出到页面中
   • token存在服务器的Session中
   • 每次页面加载时，使用JS遍历整个DOM树，对应DOM中所有的a和form标签后加入Token
2. 页面提交的请求携带这个Token
3. 服务器验证Token是否正确
   验证Token：先解密Token，对比加密字符串以及时间戳，如果加密字符串一致，且时间未过期，那么这个Token就是有效的。

这个方法，安全是非常安全的，但是工作量巨大，且可能有遗漏，因为不能在通用的拦截上统一拦截处理，需要每一个页面和接口都添加对应的输出和校验。

双重Cookie验证

要求Ajax和表单请求携带一个Cookie中的值