Web开发的安全之旅之防御篇

Web开发的安全之旅之防御篇

XSS 防御

• 永远不要相信用户提交的任何内容
• 不要将用户提交内容直接转换为DOM

XSS——现成防御工具

• 前端
• 主流框架（React、Vue）默认防御XSS
• google-closure-library
• 服务端
• 对应的包——DOMPurify

用户需求必须动态生成DOM下XSS攻击情形

• 第一种：string——>DOM
• 使用new DOMParser()类似API前必须将字符串进行转译

• 第二种：允许用户上传svg
• 提前扫描svg标签，防止中间插入script脚本恶意代码

第三种：自定义跳转链接

• 尽量不要让用户自定义跳转行为，如果做也一定要提前过滤

• 第四种：自定义样式
• 攻击者通过伪造一个CSS代码在指定情况下来发送一个请求，而导致攻击

Content Security Policy(CSP)

内容安全策略(CSP)

• CSP允许开发者去定义那些源 域名被认为是安全的
• 来自安全源的脚本可以执行，否则直接抛错
• 对eval + inline script 直接抛错
  对服务器和浏览器设置CSP的方法如下

CSRF的防御

限制请求来源

服务器端开发人员可以校验接收的Origin或者Referer进行校验，如果是当前服务器的域名那么就放行请求，如果不是则拒绝请求

token

在服务器接收到一个合法页面请求时，服务器可以通过标识来判断是否是一个合法来源的请求

• 具体流程
• 浏览器先向服务器发送一个页面的请求
• 服务器接收到这个请求后，会返回页面以及一个token给浏览器
• 浏览器之后在请求任意API的时候还会把这个token带上
• 服务器之后会对这个token进行校验，如果校验不通过，那么直接报错不返回具体数据，如果校验通过则返回真实数据
  注：
• token往往和用户是进行绑定的：攻击者也可以是注册用户===可以获取自己的的token
• token有过期时间：保证token的丢失不会影响到用户前后信息

iframe攻击

• 限制Origin，攻击者会使用同源请求来到达攻击
• 使用iframe来到达绕过Origin限制达到攻击

如何防御：在服务端设置X-Frame-Options响应头来限制这种攻击

避免用户信息被携带:SameSite Cookie

• SameSite Cookie是最近比较常见的解决方式，CSRF的攻击是由于携带了用户cookie，于是不携带cookie,我页面的Cookie只能为我所用，就从根源上解决了这种CSRF攻击

• 在相同域名下的Cookie是第一方Cookie 也就是SameSite Cookie, 不同则是第三方Cookie,也就归为非SameSite Cookie
• 当发送请求时，第一方Cookie则被携带上，第三方Cookie则不被携带上
  故此SameSite Cookie限制的是Cookie domain和当前页面域名是否匹配

浏览器依赖Cookie的第三方服务怎么办？

例如内嵌一个X站播放器，识别不了用户登录态，发布了弹幕
解决方法在服务端设置Set-Cookie属性

SameSite Cookie VS CORS

防御CSRF的正确姿势

做一个防御CSRF中间件，负责生成各类防御策略，在一处保证整个Web App都能对CSRF的防御

Injection 防御

• 找到项目中查询SQL的地方
• 使用prepared statement进行预编译
  其他防御措施如下：
  拒绝、过滤关键词等
  

DOS 防御

Regex DOS防御

• 完善Code Review，拒绝写出类似/(ab*)+/贪婪的匹配正则表达式
• 使用一些代码扫描工具去——> 代码扫描 + 正则性能测试
• 拒绝用户提供的使用正则

DDoS 防御

大体思路如下

• 流量治理
• 快速自动扩容
• 非核心服务降级

传输层————防御中间人

使用HTTPS代替HTTP协议

HTTPS 的一些特性

• 可靠性：加密，避免明文传输
• 完整性：MAC验证，确保数据没有被篡改
• 不可抵赖性：数字签名， 确保双方身份是可被信任的