深入Web安全（防御篇)

前言

随着互联网的高速发展，信息安全问题已经成为企业最为关注的焦点之一，而前端又是引发企业安全问题的高危据点。在移动互联网时代，前端人员除了传统的 XSS、CSRF 等安全问题之外，又时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。当然，浏览器自身也在不断在进化和发展，不断引入 CSP、Same-Site Cookies 等新技术来增强安全性，但是仍存在很多潜在的威胁，这需要前端技术人员不断进行“查漏补缺”，上篇介绍的是攻击篇，这篇我们来讲讲如何防御这些攻击~

一、XSS攻击的防御

XSS攻击防御的理念就是永远不要相信用户！永远不要相信用户！

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

1.1 防御XSS攻击的现成工具

前端：

• 主流框架默认防御XSS
• google-closure-library 服务端(Node)：
• DOMPurify

1.2 需要动态生成DOM

将string转化成DOM

可以使用new DOMParser()API，这种时候一定要对string进行过滤

上传SVG

SVG中可以内嵌script标签，会导致在这段SVG在浏览器加载的时候完成XSS攻击，因此对用户上传的SVG文件也要进行过滤。

<svg><script>alert("xss");</script>
</svg> 

自定义跳转链接

如果允许用户自定义跳转链接的话一定要过滤。

<a href="javascript:alert('xss')"></a> 

自定义样式

尽量不要允许用户自定义样式。

1.3 Content Security Policy(CSP)

• 哪些源（域名）被认为是安全的
• 来自安全源的脚本可以执行，否则直接抛错
• 对eval + inline script 说🙅‍

如何配置

服务器的响应头部：

Content-Security-Policy: script-src 'self' 同源
Content-Security-Pplicy: script-src 'self' https://domain.com 

浏览器meta：

<meta http-equiv="Content-Security-Policy" content="script-src self"> 

二、CSRF的防御

我们知道在CSRF中，请求是伪造的，也就是它所有的请求来源都是异常的，不是真正的域名，那我们四不是可以限制请求来源从而达到限制伪造请求的目的呢，答案是可以的。

2.1 token

2.2 限制iframe攻击

2.3 避免用户信息被携带：SameSite Cookie

2.4 防御CSRF的正确姿势

如果对每一个接口都做CSRF防御，那些太累了，又或者说，不够优雅，应该在中间件中统一处理CSRF的防御工作。

三、SQL注入的防御

• 找到项目中查询SQL的地方
• 使用prepared statement

四、其他注入的防御

五、防御DDoS

六、防御中间人

https的介入

HTTPS的一些特性

• 可靠性：加密

• 完整性：MAC验证

• 不可抵赖性：数字签名

HTTP Strict-Transport-Security(HSTS)

Subresource Integrity(SRI)

对比一个静态文件的hash值是否被篡改