浅谈web安全防范
随着互联网技术和web开发领域的飞速发展，当下的web安全问题也越来越重要，成为开发中不可小觑的一个部分。
本文我将带着大家从一些常见的安全问题入手，探讨如何在开发过程中尽可能的避免一些可能会出现的安全问题以及一些安全防范的知识点。
日常web开发项目中可能会遇到哪些安全问题呢？
常见的攻击方式有xss、csrf、点击劫持、中间人攻击.......，那么这些攻击方式分别是什么，是如何进行攻击，我们又怎么样来进行相对的防御呢？接下来我们一一来进行了解与探究。
XSS
XSS简单点来说就是攻击者会利用一切可能的方式将可执行的代码注入到网页中。
XSS可以分为多种类型，但整体上分为两类：持久型和非持久型。
持久型也就是将攻击的代码被服务端写入进数据库中，这种攻击危害性很大，因为如果网站访问量很大的话，就会导致大量正常访问页面的用户都受到攻击。
比如带有评论功能的网站，如果我在评论框输入以下内容
WX20190606-164529@2x.png
如果前后端没有做好相应的防御，这段评论就会被存储进数据库中，这样每个打开该页面的用户都会被攻击到。这种便是持久型攻击的一个例子。
相比于持久型攻击，非持久型攻击的危害就小的多了。一般是通过修改URL参数 的方式加入攻击代码，诱导用户访问链接从而进行攻击。
举个例子，如果页面需要从 URL 中获取某些参数作为内容的话，不经过过滤就会导致攻击代码被执行。
<!-- http://www.domain.com?name=<script>alert(1)</script> -->
<div>{{name}}</div>
但是对于这种攻击方式来说，如果用户使用 Chrome 这类浏览器的话，浏览器就能自动帮助用户防御攻击。但是我们不能因此就不防御此类攻击了，因为我不能确保用户都使用了该类浏览器。
知道了XSS攻击者是如何对我们的网站进行攻击的，那么我们该如何去做出相应的防御呢？
通常可以通过转义字符和CSP的方式进行防御。
转义字符
首先，对于用户的输入应该是永远不信任的。最普遍的做法就是转义输入输出的内容，对于引号、尖括号、斜杠进行转义
function escape(str) {
str = str.replace(/&/g, '&')
str = str.replace(/</g, '<')
str = str.replace(/>/g, '>')
str = str.replace(/"/g, '&quto;')
str = str.replace(/'/g, ''')
str = str.replace(/`/g, '`')
str = str.replace(/\//g, '/')
return str
}
通过转义可以将攻击代码 <script>alert(1)</script> 变成
// -> <script>alert(1)</script>
escape('<script>alert(1)</script>')
但是对于显示富文本来说，显然不能通过上面的办法来转义所有字符，因为这样会把需要的格式也过滤掉。对于这种情况，通常采用白名单过滤的办法，当然也可以通过黑名单过滤，但是考虑到需要过滤的标签和标签属性实在太多，更加推荐使用白名单的方式。
const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
// -> <h1>XSS Demo</h1><script>alert("xss");</script>
console.log(html)
以上示例使用了 js-xss 来实现，可以看到在输出中保留了 h1 标签且过滤了 script 标签。
CSP
CSP 本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击。
通常可以通过两种方式来开启 CSP：
1.设置 HTTP Header 中的 Content-Security-Policy
2.设置 meta 标签的方式 <meta http-equiv="Content-Security-Policy">
这里以设置 HTTP Header 的方式举例：
- 只允许加载本站资源
Content-Security-Policy: default-src ‘self’
- 只允许加载 HTTPS 协议图片
Content-Security-Policy: img-src https://*
可设置的更多属性大家可以通过查阅 MDN的 文档 去设置。
另附上知乎上关于 CSP 的回答。 Content Security Policy (CSP) 是什么？为什么它能抵御 XSS 攻击？
CSRF
CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。原理就是攻击者构造出一个后端请求地址，诱导用户点击或者通过某些途径自动发起请求。如果用户是在登录状态下的话，后端就以为是用户在操作，从而进行相应的逻辑。
CSRF的攻击思想如下图所示：
2009040916453171.jpg
举个例子，假设网站中有一个通过 GET 请求提交用户评论的接口，那么攻击者就可以在钓鱼网站中加入一个图片，图片的地址就是评论接口。
<img src="http://www.domain.com/xxx?comment='attack'"/>
那么你是否会想到使用 POST 方式提交请求是不是就没有这个问题了呢？其实并不是，使用这种方式也不是百分百安全的，攻击者同样可以诱导用户进入某个页面，在页面中通过表单提交 POST 请求。
防范CSRF攻击可以遵循以下几种规则：
- GET 请求不对数据进行修改
- 不让第三方网站访问到用户 Cookie
- 阻止第三方网站请求接口
- 请求时附带验证信息，比如验证码或者 Token
SameSite
可以对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送，可以很大程度减少 CSRF 的攻击，但是该属性目前并不是所有浏览器都兼容。
验证 Referer
对于需要防范 CSRF 的请求，我们可以通过验证 Referer 来判断该请求是否为第三方网站发起的。
Token
服务器下发一个随机 Token，每次发起请求时将 Token 携带上，服务器验证 Token 是否有效。
中间人攻击
中间人攻击是攻击方同时与服务端和客户端建立起了连接，并让对方认为连接是安全的，但是实际上整个通信过程都被攻击者控制了。攻击者不仅能获得双方的通信信息，还能修改通信信息。
通常来说不建议使用公共的 Wi-Fi，因为很可能就会发生中间人攻击的情况。如果你在通信的过程中涉及到了某些敏感信息，就完全暴露给攻击方了。
以上就是整理的一些web安全问题和防御策略，安全是个极大的问题和方向，需要我们开发人员不懈的努力共同去解决。如果大家有什么更好的见解，欢迎在评论中一起讨论。
