前言
Web攻击（WebAttack）是针对用户上网行为或网站服务器等设备进行攻击的行为，如植入恶意代码，修改网站权限，获取网站用户隐私信息等等。
常见的Web攻击方式有以下几种
- XSS (Cross Site Scripting) 跨站脚本攻击
- CSRF（Cross-site request forgery）跨站请求伪造
- SQL注入攻击
本文主要讲解CSRF方面。
CSRF是什么
CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求，利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
一个典型的CSRF攻击有着如下的流程：
- 受害者登录a.com，并保留了登录凭证（Cookie）。
- 攻击者引诱受害者访问了b.com。
- b.com 向 a.com 发送请求。
- a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
- a.com以受害者的名义执行了这个请求。
- 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。
CSRF的特点
- 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生
- 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据
- 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是"冒用"
- 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。
如何进行预防
CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。
防止csrf常用方案如下：
-
阻止不明外域的访问
- 同源检测
- Samesite Cookie
-
提交时要求附加本域才能获取的信息
- CSRF Token
- 双重Cookie验证
同源检测
Cookie的同源和浏览器的同源策略有所区别：
- 浏览器同源策略：协议、域名和端口都相同即同源；
- Cookie同源策略：域名相同即同源；
在HTTP协议中，每个异步请求都会携带两个header,用来标记来源域名：
- Origin Header
- Referer Header
这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端修改，服务器接收到后可以根据这两个Header确定来源的域名；
综上所述： 同源验证是一个相对简单的防范方法，能够防范绝大多数的CSRF攻击。但这并不是万无一失的，对于安全性要求较高，或者有较多用户输入内容的网站，我们就要对关键的接口做额外的防护措施。
Samesite Cookie属性
在Chrome 51版本后，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 CSRF 攻击。
Cookie的Samesite属性用来限制第三方Cookie, 从而减少安全风险，它有三个值：
- Set-Cookie: SameSite = Strict;
- Set-Cookie: SameSite = Lax;
- Set-Cookie: SameSite = None;
Strict： 最为严格，完全禁止第三方Cookie, 跨站点时，任何情况都不发送Cookie;
Lax： 限制稍微宽松，大多数情况下时不发送第三方Cookie的，除了a链接、预加载请求和GET表单；
None： 关闭SameSite属性，但必须同时设置Secure属性，
CSRF token
CSRF token的防护策略分为三步：
-
将token输出到页面 首先，用户打开页面的时候，服务器需要给这个用户生成一个Token，该Token通过加密算法对数据进行加密，一般Token都包括随机字符串和时间戳的组合，显然在提交时Token不能再放在Cookie中了，否则又会被攻击者冒用。
-
请求中携带token
-
服务端验证token是否正确 服务端拿到客户端给的token后，先解密token,再比对随机字符串是否一致、时间是否有效，如果字符串对比一致且在有效期内，则说明token正确。