CSRF(Cross-Site Request Forgery )
跨站请求伪造：CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
一个典型的 CSRF 攻击有着如下的流程：
- 受害者登录 a.com，并保留了登录凭证（Cookie）。
- 攻击者引诱受害者访问了 b.com。
- b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带 a.com 的 Cookie。
- a.com 接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
- a.com 以受害者的名义执行了 act=xx。
- 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让 a.com 执行了自己定义的操作。
几种常见的攻击类型
GET类型的CSRF
GET类型的CSRF利用非常简单，只需要一个HTTP请求，一般会这样利用：
在受害者访问含有这个img的页面后，浏览器会自动向
http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。POST类型的CSRF
这种类型的CSRF利用起来通常使用的是一个自动提交的表单，如：
<form action="http://bank.example/withdraw" method=POST> <input type="hidden" name="account" value="xiaoming" /> <input type="hidden" name="amount" value="10000" /> <input type="hidden" name="for" value="hacker" /></form><script> document.forms[0].submit(); </script>
访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。
POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面。
链接类型的CSRF
链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如：
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank"> 重磅消息！！ <a/>
由于之前用户登录了信任的网站A，并且保存登录状态，只要用户主动访问上面的这个页面，则表示攻击成功。
CSRF 分析
csrf 能成功的原因在于：借助浏览器 cookie 的机制，非法使用了用户的 cookie。攻击者无法读取和操作 cookie，只是发起伪造请求，带上了 cookie。
特点：
- 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
- 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
- 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
- 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。
CSRF 防范策略
- 阻止不明外域的访问
- 同源检测
- Samesite Cookie
- 提交时要求附加本域才能获取的信息
- CSRF Token
- 双重Cookie验证
要防止字段信息保存在 cookie 中，所以可以保存在 session 中。在渲染完页面后，利用 js 脚本在表单提交中新增默认字段，或者在请求中 url 中携带字段。
对于大型网站，session 维护会有成本。可以使用一些通用的分布式 token 设计，服务端不需要存储 session，只需要对 token 的合法性进行一次计算验证即可。
防护具体说明
同源检测
既然CSRF大多来自第三方网站，那么我们就直接禁止外域（或者不受信任的域名）对我们发起请求。
那么问题来了，我们如何判断请求是否来自外域呢？
在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：
- Origin Header
- Referer Header
这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。 服务器可以通过解析这两个Header中的域名，确定请求的来源域
在部分与CSRF有关的请求中，请求的Header中会携带Origin字段。字段内包含请求的域名（不包含path及query）。
如果Origin存在，那么直接使用Origin中的字段确认来源域名就可以。
但是Origin在以下两种情况下并不存在：
- IE11同源策略： IE 11 不会在跨站CORS请求上添加Origin标头，Referer头将仍然是唯一的标识。最根本原因是因为IE 11对同源的定义和其他浏览器有不同，有两个主要的区别。
- 302重定向： 在302重定向之后Origin不包含在重定向的请求中，因为Origin可能会被认为是其他来源的敏感信息。对于302重定向的情况来说都是定向到新的服务器上的URL，因此浏览器不想将Origin泄漏到新的服务器上。
根据HTTP协议，在HTTP头中有一个字段叫Referer，记录了该HTTP请求的来源地址。 对于Ajax请求，图片和script等资源请求，Referer为发起请求的页面地址。对于页面跳转，Referer为打开页面历史记录的前一个页面地址。因此我们使用Referer中链接的Origin部分可以得知请求的来源域名。
这种方法并非万无一失，Referer的值是由浏览器提供的，虽然HTTP协议上有明确的要求，但是每个浏览器对于Referer的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不是很安全。在部分情况下，攻击者可以隐藏，甚至修改自己请求的Referer。
2014年，W3C的Web应用安全工作组发布了Referrer Policy草案，对浏览器该如何发送Referer做了详细的规定。截止现在新版浏览器大部分已经支持了这份草案，我们终于可以灵活地控制自己网站的Referer策略了。新版的Referrer Policy规定了五种Referer策略：No Referrer、No Referrer When Downgrade、Origin Only、Origin When Cross-origin、和 Unsafe URL。之前就存在的三种策略：never、default和always，在新标准里换了个名称。他们的对应关系如下：
策略名称 | 属性值（新） | 属性值（旧） |
No Referrer | no-Referrer | never |
No Referrer When Downgrade | no-Referrer-when-downgrade | default |
Origin Only | (same or strict) origin | origin |
Origin When Cross Origin | (strict) origin-when-crossorigin | - |
Unsafe URL | unsafe-url | always |
根据上面的表格因此需要把Referrer Policy的策略设置成same-origin，对于同源的链接和引用，会发送Referer，referer值为Host不带Path；跨域访问则不携带Referer。例如：
aaa.com引用bbb.com的资源，不会发送Referer。设置Referrer Policy的方法有三种：
- 在CSP设置
- 页面头部增加meta标签
- a标签增加referrerpolicy属性
CSRF Token
前面讲到CSRF的另一个特征是，攻击者无法直接窃取到用户的信息（Cookie，Header，网站内容等），仅仅是冒用Cookie中的信息。
而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。
原理
CSRF Token的防护策略分为三个步骤：
1. 将CSRF Token输出到页面中
首先，用户打开页面的时候，服务器需要给这个用户生成一个Token，该Token通过加密算法对数据进行加密，一般Token都包括随机字符串和时间戳的组合，显然在提交时Token不能再放在Cookie中了，否则又会被攻击者冒用。因此，为了安全起见Token最好还是存在服务器的Session中，之后在每次页面加载时，使用JS遍历整个DOM树，对于DOM中所有的a和form标签后加入Token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的HTML代码，这种方法就没有作用，还需要程序员在编码时手动添加Token。
2. 页面提交的请求携带这个Token
对于GET请求，Token将附在请求地址之后，这样URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上：
<input type=”hidden” name=”csrftoken” value=”tokenvalue”/>
这样，就把Token以参数的形式加入请求了。
3. 服务器验证Token是否正确
当用户从客户端得到了Token，再次提交给服务器的时候，服务器需要判断Token的有效性，验证过程是先解密Token，对比加密字符串以及时间戳，如果加密字符串一致且时间未过期，那么这个Token就是有效的。
这种方法要比之前检查Referer或者Origin要安全一些，Token可以在产生并放于Session之中，然后在每次请求时把Token从Session中拿出，与请求中的Token进行比对，但这种方法的比较麻烦的在于如何把Token以参数的形式加入请求。
双重Cookie验证
在会话中存储CSRF Token比较繁琐，而且不能在通用的拦截上统一处理所有的接口。
那么另一种防御措施是使用双重提交Cookie。利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。
双重Cookie采用以下流程：
- 在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如
csrfcookie=v8g9e4ksfhw）。
- 在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例
POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
- 后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。
此方法相对于CSRF Token就简单了许多。可以直接通过前后端拦截的的方法自动化实现。后端校验也更加方便，只需进行请求中字段的对比，而不需要再进行查询和存储Token。
当然，此方法并没有大规模应用，其在大型网站上的安全性还是没有CSRF Token高，原因我们举例进行说明。
由于任何跨域都会导致前端无法获取Cookie中的字段（包括子域名之间），于是发生了如下情况：
- 如果用户访问的网站为
www.a.com，而后端的api域名为api.a.com。那么在www.a.com下，前端拿不到api.a.com的Cookie，也就无法完成双重Cookie认证。
- 于是这个认证Cookie必须被种在
a.com下，这样每个子域都可以访问。
- 任何一个子域都可以修改
a.com下的Cookie。
- 某个子域名存在漏洞被XSS攻击（例如
upload.a.com）。虽然这个子域下并没有什么值得窃取的信息。但攻击者修改了a.com下的Cookie。
- 攻击者可以直接使用自己配置的Cookie，对XSS中招的用户再向
www.a.com下，发起CSRF攻击。
总结：
用双重Cookie防御CSRF的优点：
- 无需使用Session，适用面更广，易于实施。
- Token储存于客户端中，不会给服务器带来压力。
- 相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。
缺点：
- Cookie中增加了额外的字段。
- 如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。
- 难以做到子域名的隔离。
- 为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。
Samesite Cookie属性
防止CSRF攻击的办法已经有上面的预防措施。为了从源头上解决这个问题，Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax，下面分别讲解：
Samesite=Strict
这种称为严格模式，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie，绝无例外。比如说 b.com 设置了如下 Cookie：
Set-Cookie: foo=1; Samesite=StrictSet-Cookie: bar=2; Samesite=LaxSet-Cookie: baz=3
我们在 a.com 下发起对 b.com 的任意请求，foo 这个 Cookie 都不会被包含在 Cookie 请求头中，但 bar 会。举个实际的例子就是，假如淘宝网站用来识别用户登录与否的 Cookie 被设置成了 Samesite=Strict，那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后，淘宝都不会是登录状态，因为淘宝的服务器不会接受到那个 Cookie，其它网站发起的对淘宝的任意请求都不会带上那个 Cookie。
Samesite=Lax
这种称为宽松模式，比 Strict 放宽了点限制：假如这个请求是这种请求（改变了当前页面或者打开了新页面）且同时是个GET请求，则这个Cookie可以作为第三方Cookie。比如说 b.com设置了如下Cookie：
Set-Cookie: foo=1; Samesite=StrictSet-Cookie: bar=2; Samesite=LaxSet-Cookie: baz=3
当用户从 a.com 点击链接进入 b.com 时，foo 这个 Cookie 不会被包含在 Cookie 请求头中，但 bar 和 baz 会，也就是说用户在不同网站之间通过链接跳转是不受影响了。但假如这个请求是从 a.com 发起的对 b.com 的异步请求，或者页面跳转是通过表单的 post 提交触发的，则bar也不会发送。
XSS Cross-site Script
跨站脚本攻击：一般是指攻击者通过在网页中注入恶意脚本，当用户浏览网页时，恶意脚本执行，控制用户浏览器行为的一种攻击方式。
常见 XSS 危害有：
- 窃取用户 Cookie，获取用户隐私，盗取用户账号。
- 劫持用户（浏览器）会话，从而执行任意操作，例如进行非法转账、强制发表日志、发送电子邮件等。
- 强制弹出广告页面，刷流量，传播跨站脚本蠕虫，网页挂马等。
- 结合其他漏洞，如 CSRF 漏洞，实施进一步的攻击。
XSS分类
XSS防御
1：浏览器自带防御 （X-XSS-Protection ）
现今主流浏览器（Internet Explorer，Chrome 和 Safari）带有 HTTP
X-XSS-Protection 响应头，当检测到跨站脚本攻击(XSS)时，浏览器将停止加载页面。X-XSS-Protection 响应头有以下 4 个值：X-XSS-Protection: 0
禁止 XSS 过滤。
X-XSS-Protection: 1
启用 XSS 过滤（通常浏览器是默认的）。 如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。
X-XSS-Protection: 1; mode=block
启用 XSS 过滤。 如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。
X-XSS-Protection: 1; report=<reporting-uri>
启用 XSS 过滤。 如果检测到跨站脚本攻击，浏览器将清除页面并使用 CSP report-uri 指令的功能发送违规报告。
这并不能完全防止反射型 XSS，而且也并不是所有浏览器都支持
X-XSS-Protection，存在兼容性问题。它只对反射型 XSS 有一定的防御力，其原理也只是检查 URL 和 DOM 中元素的相关性。
2：转义
即将常用特殊字符进行转义，避免攻击者使用构造特殊字符来注入脚本。需要在客户端和服务端，都对用户输入的数据进行转义。
常见需要转义的特殊字符如
<，>，&，"，'。转义方法：
function escapeHTML(str) { if (!str) return ''; str = str.replace(/&/g, "&"); str = str..replace(/</g, "<"); str = str..replace(/>/g, ">"); str = str..replace(/"/g, """); str = str..replace(/'/g, "'"); return str;};
3：过滤
常见于富文本内容，因为其需要保留 HTML，所以不能直接使用转义方法，而可以通过使用白名单，来允许特定的 HTML 标签及属性，来抵御 XSS 攻击。
4：内容安全策略（CSP）
内容安全策略（Content Security Policy，CSP），实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，大大增强了网页的安全性。
两种方法可以启用 CSP。
- 通过 HTTP 头信息的
Content-Security-Policy的字段：
Content-Security-Policy: script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:
- 通过网页的 标签
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
上面代码中，CSP 做了如下配置：
- 脚本： 只信任当前域名
<object>标签： 不信任任何 URL，即不加载任何资源
- 样式表： 只信任
cdn.example.org和third-party.org
- 页面子内容，如
<frame>、<iframe>： 必须使用 HTTPS 协议加载
- 其他资源： 没有限制
- 启用后，不符合 CSP 的外部资源就会被阻止加载。
SQL注入
例如做一个系统的登录界面，输入用户名和密码，提交之后，后端直接拿到数据就拼接 SQL 语句去查询数据库。如果在输入时进行了恶意的 SQL 拼装，那么最后生成的 SQL 就会有问题。
比如后端拼接的 SQL 字符串是：
SELECT * FROM user WHERE username = 'user' AND password = 'pwd';
如果不做任何防护，直接拼接前端的字符，就会出现问题。比如前端传来的
user字段是以'#结尾，password随意：SELECT * FROM user WHERE username = 'user'#'AND password = 'pwd';
密码验证部分直接被注释掉了。
防范
后端应该对于字符串有转义，可以借助成熟的库的 API 来拼接命令，而不是自己手动拼接。
点击劫持
攻击原理
点击劫持是一种视觉欺骗的攻击手段。攻击者通过
iframe 嵌套嵌入被攻击网页，诱导用户点击。如果用户之前登陆过被攻击网页，那么浏览器可能保存了信息，因此可以以用户的身份实现操作。中间人攻击
原理
它也被称为浏览器劫持、web 劫持。可以往 web 中添加一些第三方厂商的 dom 元素，或者重定向到另外的钓鱼站。
常用手段有 2 种：
- 网络报文传输过程中对其截获、篡改（过程中）
- 客户端发起 http 请求之前或者得到 response 之后对数据篡改（开头、结尾）
防范方式就是使用
https 协议，一套在传输层 TCP 和应用层 HTTP 之间的 TLS 协议。https 交互细节
简单地说，一次 https 网络请求在建立开始阶段具有以下的一个“握手”流程：
首先，客户端向服务端发起一个基于 https 协议的网络请求，这相当于告诉它：“我希望得到一个安全加密的网页，你可别直接把明文扔过来！”
服务端接收到这个网络请求后，了解到客户端的提出的这种加密的诉求，于是先把一个公钥和网站的 https 证书发送给客户端。
客户端随后要做两件事，一是验证证书的合法性与时效性，如果颁发证书的机构客户端这边不承认或者证书中标明的过期时间已经过了，这都会导致客户端浏览器报出那个红叉子，chrome 浏览器还会直接拦截掉这个请求，除非用户点详情->继续，否则不会与该网站的服务器进行后续沟通，这相当于一个强交互的提醒，告诉用户“我拿到的证书有问题，这网站可能是个冒牌货，你要看仔细了！”
如果以上两步验证无误，那么客户端会先生成一个随机秘钥，利用刚刚拿到的公钥给自己要访问的 url+这个随机秘钥进行加密，把密文再次发往服务端。
当服务端收到客户端传过来的密文之后，会通过自己手里持有的一个私钥对密文进行解密。注意，这里提到的私钥和刚刚的公钥是一对儿秘钥，这是一个典型的非对称加密，加密和解密分别使用两把不同的钥匙，这也保证了在此场景下的安全性。
此时，服务端要将真正的 html 网页文本发给你了，它会利用解密得到的随机秘钥对网页文本内容进行加密，将密文发给客户端。
客户端拿到真正的 html 报文之后，就用自己刚才生成的那个随机秘钥进行解密，然后就得到了跟普通 http 请求时一样的一个网页文本了，在这之后就像往常那样解析、渲染、加载更多资源……
对于真正要传输的 html 文本，实际上是使用刚刚提到的这个随机秘钥进行了一次对称加密，因为上锁和开锁的钥匙实际上是一模一样的。
文章来源：1.美团技术团队