这是我参与「第四届青训营 」笔记创作活动的的第12天
Web开发的安全之旅之防御篇
大家好，这里是还在补笔记的Vic，今天给大家带来Web开发的安全之旅之防御篇。在之前的文章中，我们介绍了Web安全中的常见攻击手段，那么如何应对这些攻击呢？在这篇文章中，我们将对常见攻击的应对手段进行解答。
XSS攻击防御
在攻击篇中我们已经解释了XSS攻击的核心在于开发者直接将用户输入的数据转换为DOM元素，这就提醒我们为了防御XSS攻击，开发者需要坚持这两个原则。第一，永远不信任用户的提交内容；第二，不要将用户提交内容直接转换成DOM。
目前来说在前端中的主流框架都默认防御XSS攻击，另外也可以在前端使用google-closure-library这个库来进行防御。在服务端（Node）中则可以使用DOMPurify来进行XSS攻击的防御。
当然，有时候我们面对用户的需求，其中也可能存在必须根据用户输入的情况动态生成DOM的情况，针对这种情况，开发者需要警惕如下几种情况：
- string类型直接转换为DOM元素；
- 上传svg（这是由于svg中可能包含有恶意脚本）；
- 利用Blob动态生成script；
- 自定义跳转链接（跳转链接中可能是一个恶意脚本）；
- 自定义样式（例如在background属性中插入恶意脚本链接）
在这里补充一下浏览器的同源策略。在讲解这个概念之前，我们首先了解一下什么是同源。浏览器的同源指的是协议、域名、端口号都相同的就是同源，若有一个不同就不是同源。通过浏览器的同源策略，则JS脚本在未经允许的情况下，不能够访问其他域下的内容。通过同源策略可以有效地保证用户信息的安全。
接着再聊聊内容安全策略（CSP），这是用来防止XSS攻击的神器，我们可以把它理解为一个白名单，它决定了哪些域名是安全的，只有来自安全域名的脚本才可以执行，否则的话就会报错，且其能够有效禁止eval + inline script。相关配置如下图所示：
CSRF的防御
对CSRF的防御思路如下：对请求的来源进行判断，如果请求是伪造请求，那么其来源则为异常来源，因此可以采用限制请求来源的思路从而限制伪造请求。
具体措施是根据Origin和Referer的请求头来进行判断请求来源，这是因为前端在发起请求时无法修改设置这两个请求头。
那么除了利用 Origin + Referer 还有什么方式来判断请求是否来自于合法来源呢？我们可以使用token进行判断。这种方式的思想是利用服务器是否之前接受过页面的请求来判断是否页面为合法页面的。其主要流程是当浏览器首次向服务器请求页面时，在判断合法的情况下，将请求页面与token返回给浏览器，之后浏览器向服务器请求接口时就需要在请求头中带上这个token，服务器在验证token是否合法后，根据情况决定返回数据。
需要注意的是，攻击者也可能是注册用户或者攻击者可能会通过非法手段获取用户的token，因此需要对token设置过期时间，从而保证安全。
针对限制Origin的方法，攻击者也想出了一种新的CSRF攻击方式，即利用iframe攻击。通过这种方式，攻击者就可以将攻击转为同源请求。防御这种攻击方式，我们可以采用如下设置：X-Frame-Options: DENY/SAMEORIGIN。
要提醒开发者的是，在后端配置接口时不要将更新和获取逻辑都放到同一个GET接口中，这是由于更新请求是一个非常敏感的行为，如果采用这种行为，那么开发者将直接一石二鸟，获得很高的权限。
攻击者也可以使用携带用户信息的方式进行CSRF攻击。为了应对这种情况，可以使用SameSite Cookie方式进行防御，通过这种方式可以实现用户的cookie只能被用户本人使用，这种方式主要限制的是Cookie domain 和页面域名。在这里贴上一个用作说明的图片。
那么又出现了一个疑问，当遇到依赖cookie的第三方服务怎么办呢？一般来说可以考虑跨源资源共享（CORS）的方式，这种方式与SameSite的对比如下图所示：
在课上也介绍了一种新的方式即第三方cookie，其原理如图所示：
针对SameSite Cookie可以设置三个参数：None、Lax、Strict。
通过对首次导航的限制可以避免敏感操作跳过二次确认，比如用于重置密码的链接。
总体来说，如果利用case by case来防御，所需要的操作是十分繁琐的，因此我们最好使用一个中间件来进行CSRF防御。
注入防御
针对SQL注入攻击防御，我们可以找到项目中查询SQL的地方，然后使用 prepared statement。
针对超出SQL的注入攻击，我们在防御的时候应当
- 遵循最小权限原则，禁止用户对
sudo或root操作； - 建立允许名单并设置过滤机制，禁止
rm等命令； - 对URL类型参数进行协议、域名、IP等限制，禁止用户访问内网。
防御DOS攻击
针对涉及正则的DOS攻击，我们可以采用如下方法：
- 对代码进行审查，禁止可能造成DOS攻击的正则指令；
- 对代码进行扫描，并对正则性能进行测试；
- 进行用户使用的正则（从根源上解决问题）。
针对DDOS攻击，我们在防御时可以采用下图的手段进行防御：
防御中间人
防御中间人攻击可以采用HTTPS协议进行传输，这是因为HTTPS具有如下特性：
- 可靠性：加密
- 完整性：MAC验证
- 不可抵赖性：数字签名
关于HTTPS的具体讲解，在这里就不做讲解了，感兴趣的同学可以之后进行相关的学习。
结尾
在文章的最后，将老师课上最后附的几个推荐阅读的链接贴上来，由于时间问题，还没有阅读，希望在之后的时间里能够抽出时间对文章进行阅读。
