前言
随着互联网的高速发展，信息安全问题已经成为企业最为关注的焦点之一，而前端又是引发企业安全问题的高危据点。在移动互联网时代，前端人员除了传统的 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值是否被篡改
最后
⚽到这，我们Web安全的防御篇也就已经介绍完啦，我们要清楚安全无小事，要时刻注意网络安全问题，保持学习心态~
⚾如果你对这篇文章感兴趣欢迎点赞关注+收藏，更多精彩知识正在等你！😘
