前端安全系列之二：如何防止CSRF攻击？

配景

随着互联网的高速发展，信息安全题目已经成为企业最为关注的焦点之一，而前端又是引发企业安全题目的高危据点。在移动互联网期间，前端职员除了传统的
XSS、CSRF 等安全题目之外，又时常遭遇网络劫持、非法调用 Hybrid API 等新型安全题目。固然，欣赏器自身也在不断在进化和发展，不断引入
CSP、Same-Site Cookies 等新技术来增强安全性，但是仍存在很多潜在的威胁，这需要前端技术职员不断进行“查漏补缺”。
前端安全

近几年，美团业务高速发展，前端随之面临很多安全挑衅，因此积累了大量的实践经验。我们梳理了常见的前端安全题目以及对应的办理方案，将会做成一个系列，盼望可以帮助前端同砚在一样平常开发中不断预防和修复安全漏洞。本文是该系列的第二篇。
今天我们讲解一下
CSRF，其实相比XSS，CSRF的名气似乎并不是那么大，很多人都认为“CSRF不具备那么大的粉碎性”。真的是如许吗？接下来，我们还是有请小明同砚再次“闪亮”登场。
   [【一一帮助安全学习，所有资源获取处一一】](https://img-
blog.csdnimg.cn/img_convert/40827b849025375539c64360b039dd6d.png)
  ①网络安全学习路线
  ②20份渗透测试电子书
  ③安全攻防357页笔记
  ④50份安全攻防口试指南
  ⑤安全红队渗透工具包
  ⑥网络安全必备册本
  ⑦100个漏洞实战案例
  ⑧安全大厂内部视频资源
  ⑨积年CTF夺旗赛题解析
  CSRF攻击

CSRF漏洞的发生

相比XSS，CSRF的名气似乎并不是那么大，很多人都认为CSRF“不那么有粉碎性”。真的是如许吗？
接下来有请小明出场~~
小明的悲惨遭遇

这一天，小明同砚百无聊赖地刷着Gmail邮件。大部分都是没营养的关照、验证码、聊天记载之类。但有一封邮件引起了小明的注意：
   甩卖比特币，一个只要998！！
  智慧的小明固然知道这种肯定是骗子，但还是抱着好奇的态度点了进去（请勿模拟）。果然，这只是一个什么都没有的空缺页面，小明失望的关闭了页面。一切似乎什么都没有发生…
在这平静的外表之下，黑客的攻击已然得手。小明的Gmail中，被偷偷设置了一个过滤规则，这个规则使得所有的邮件都会被主动转发到haker@hackermail.com。小明还在继续刷着邮件，殊不知他的邮件正在一封封地，如脱缰的野马一般地，连续不断地向着黑客的邮箱转发而去。
不久之后的一天，小明发现本身的域名已经被转让了。懵懂的小明以为是域名到期本身忘了续费，直到有一天，对方开出了 $650 的赎回价码，小明才开始以为不太对劲。
小明仔细查了下域名的转让，对方是拥有本身的验证码的，而域名的验证码只存在于本身的邮箱里面。小明回想起那天希奇的链接，打开后重新检察了“空缺页”的源码：

1. 复制代码<form method="POST" action="https://mail.google.com/mail/h/ewt1jmuj4ddv/?v=prf" enctype="multipart/form-data">
2.     <input type="hidden" name="cf2_emc" value="true"/>
3.     <input type="hidden" name="cf2_email" value="hacker@hakermail.com"/>
4.     .....
5.     <input type="hidden" name="irf" value="on"/>
6.     <input type="hidden" name="nvp_bu_cftb" value="Create Filter"/>
7. </form>
8. <script>
9.     document.forms[0].submit();
10. </script>

复制代码

  这个页面只要打开，就会向Gmail发送一个post请求。请求中，实行了“Create
Filter”命令，将所有的邮件，转发到“hacker@hakermail.com”。
  小明由于刚刚就登岸了Gmail，以是这个请求发送时，携带着小明的登录凭证（Cookie），Gmail的后台接收到请求，验证了确实有小明的登录凭证，于是乐成给小明设置了过滤器。
  黑客可以检察小明的所有邮件，包括邮件里的域名验证码等隐私信息。拿到验证码之后，黑客就可以要求域名服务商把域名重置给本身。
  小明很快打开Gmail，找到了那条过滤器，将其删除。然而，已经泄漏的邮件，已经被转让的域名，再也无法挽回了…
以上就是小明的悲惨遭遇。而“点开一个黑客的链接，所有邮件都被窃取”这种变乱并不是杜撰的，此变乱原型是2007年Gmail的CSRF漏洞：
[www.davidairey.com/google-Gmai…]
固然，现在此漏洞已被Gmail修复，请使用Gmail的同砚不要慌张。
什么是CSRF

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请求，一般会如许使用：

1. 复制代码 <img src="http://bank.example/withdraw?amount=10000&for=hacker" >

复制代码

在受害者访问含有这个img的页面后，欣赏器会主动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。

• POST范例的CSRF
  

这种范例的CSRF使用起来通常使用的是一个主动提交的表单，如：

1. 复制代码 <form action="http://bank.example/withdraw" method=POST>
2.     <input type="hidden" name="account" value="xiaoming" />
3.     <input type="hidden" name="amount" value="10000" />
4.     <input type="hidden" name="for" value="hacker" />
5. </form>
6. <script> document.forms[0].submit(); </script>

复制代码

访问该页面后，表单会主动提交，相当于模拟用户完成了一次POST操作。
POST范例的攻击通常比GET要求更加严酷一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的泉源，后端接口不能将安全拜托在仅答应POST上面。

• 链接范例的CSRF
  

链接范例的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种范例通常是在论坛中发布的图片中嵌入恶意链接，大概以广告的情势诱导用户中招，攻击者通常会以比较浮夸的词语诱骗用户点击，例如：

1. 复制代码  <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
2.   重磅消息！！
3.   <a/>

复制代码

由于之前用户登录了信托的网站A，而且保存登录状态，只要用户主动访问上面的这个PHP页面，则表示攻击乐成。
CSRF的特点

• 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
  
• 攻击使用受害者在被攻击网站的登录凭证，假冒受害者提交操作；而不是直接窃取数据。
  
• 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
  
• 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
  

CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是假如本域下有容易被使用的功能，好比可以发图和链接的论坛和品评区，攻击可以直接在本域下进行，而且这种攻击更加伤害。
防护计谋

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强本身网站针对CSRF的防护能力来提拔安全性。
上文中讲了CSRF的两个特点：

• CSRF（通常）发生在第三方域名。
  
• CSRF攻击者不能获取到Cookie等信息，只是使用。
  

针对这两点，我们可以专门制定防护计谋，如下：

• 阻止不明外域的访问
  
  
  
  • 同源检测
    
  • Samesite Cookie
    
  
  
• 提交时要求附加本域才华获取的信息
  
  
  
  • CSRF Token
    
  • 双重Cookie验证
    
  
  

以下我们对各种防护方法做具体说明：
同源检测

既然CSRF大多来自第三方网站，那么我们就直接禁止外域（大概不受信托的域名）对我们发起请求。
那么题目来了，我们如何判定请求是否来自外域呢？
在HTTP协议中，每一个异步请求都会携带两个Header，用于标志泉源域名：

• Origin Header
  
• Referer Header
  

这两个Header在欣赏器发起请求时，大多数情况会主动带上，而且不能由前端自定义内容。服务器可以通过解析这两个Header中的域名，确定请求的泉源域。
使用Origin Header确定泉源域名

在部分与CSRF有关的请求中，请求的Header中会携带Origin字段。字段内包含请求的域名（不包含path及query）。
假如Origin存在，那么直接使用Origin中的字段确认泉源域名就可以。
但是Origin在以下两种情况下并不存在：

• IE11同源计谋： IE 11 不会在跨站CORS请求上添加Origin标头，Referer头将仍然是唯一的标识。最根本原因是因为IE 11对同源的定义和其他欣赏器有不同，有两个主要的区别，可以参考MDN Same-origin_policy#IE_Exceptions
  
• 302重定向： 在302重定向之后Origin不包含在重定向的请求中，因为Origin可能会被认为是其他泉源的敏感信息。对于302重定向的情况来说都是定向到新的服务器上的URL，因此欣赏器不想将Origin泄漏到新的服务器上。
  

使用Referer Header确定泉源域名

根据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 Referrerno-ReferrerneverNo Referrer When Downgradeno-Referrer-when-downgradedefaultOrigin Only(same or strict) originoriginOrigin When Cross Origin(strict) origin-when-crossorigin-Unsafe URLunsafe-urlalways 根据上面的表格因此需要把Referrer Policy的计谋设置成same-
origin，对于同源的链接和引用，会发送Referer，referer值为Host不带Path；跨域访问则不携带Referer。例如：aaa.com引用bbb.com的资源，不会发送Referer。
设置Referrer Policy的方法有三种：

• 在CSP设置
  
• 页面头部增长meta标签
  
• a标签增长referrerpolicy属性
  

上面说的这些比较多，但我们可以知道一个题目：攻击者可以在本身的请求中隐藏Referer。假如攻击者将本身的请求如许填写：

1. 复制代码 <img src="http://bank.example/withdraw?amount=10000&for=hacker" referrerpolicy="no-referrer">

复制代码

那么这个请求发起的攻击将不携带Referer。
另外在以下情况下Referer没有大概不可信：
1.IE6、7下使用window.location.href=url进行界面的跳转，会丢失Referer。
2.IE6、7下使用window.open，也会缺失Referer。
3.HTTPS页面跳转到HTTP页面，所有欣赏器Referer都丢失。
4.点击Flash上到达另外一个网站的时候，Referer的情况就比较紊乱，不太可信。
无法确认泉源域名情况

当Origin和Referer头文件不存在时该怎么办？假如Origin和Referer都不存在，发起直接进行阻止，特别是假如您没有使用随机CSRF
Token（参考下方）作为第二次查抄。
如何阻止外域请求

通过Header的验证，我们可以知道发起请求的泉源域名，这些泉源域名可能是网站本域，大概子域名，大概有授权的第三方域名，又大概来自不可信的未知域名。
我们已经知道了请求域名是否是来自不可信的域名，我们直接阻止掉这些的请求，就能防御CSRF攻击了吗？
且慢！当一个请求是页面请求（好比网站的主页），而泉源是搜索引擎的链接（例如百度的搜索结果），也会被当成疑似CSRF攻击。以是在判定的时候需要过滤掉页面请求情况，通常Header符合以下情况：

1. 复制代码Accept: text/html
2. Method: GET

复制代码

但相应的，页面请求就暴露在了CSRF的攻击范围之中。假如你的网站中，在页面的GET请求中对当前用户做了什么操作的话，防范就失效了。
例如，下面的页面请求：

1. 复制代码GET https://example.com/addComment?comment=XXX&dest=orderId

复制代码

注：这种严酷来说并不一定存在CSRF攻击的风险，但仍然有很多网站经常把主文档GET请求挂上参数来实现产物功能，但是如许做对于自身来说是存在安全风险的。
另外，前面说过，CSRF大多数情况下来自第三方域名，但并不能清除本域发起。假如攻击者有权限在本域发布品评（含链接、图片等，统称UGC），那么它可以直接在本域发起攻击，这种情况下同源计谋无法到达防护的作用。
综上所述：同源验证是一个相对简单的防范方法，能够防范绝大多数的CSRF攻击。但这并不是十拿九稳的，对于安全性要求较高，大概有较多用户输入内容的网站，我们就要对关键的接口做额外的防护步伐。
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 的最后加上：

1. 复制代码 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>

复制代码

如许，就把Token以参数的情势加入请求了。
3.服务器验证Token是否精确
当用户从客户端得到了Token，再次提交给服务器的时候，服务器需要判定Token的有效性，验证过程是先解密Token，对比加密字符串以及时间戳，假如加密字符串一致且时间未过期，那么这个Token就是有效的。
这种方法要比之前查抄Referer大概Origin要安全一些，Token可以在产生并放于Session之中，然后在每次请求时把Token从Session中拿出，与请求中的Token进行比对，但这种方法的比较麻烦的在于如何把Token以参数的情势加入请求。下面将以Java为例，介绍一些CSRF
Token的服务端校验逻辑，代码如下：

1. 复制代码HttpServletRequest req = (HttpServletRequest)request;
2. HttpSession s = req.getSession();
4. // 从 session 中得到 csrftoken 属性
5. String sToken = (String)s.getAttribute(“csrftoken”);
6. if(sToken == null){
7.    // 产生新的 token 放入 session 中
8.    sToken = generateToken();
9.    s.setAttribute(“csrftoken”,sToken);
10.    chain.doFilter(request, response);
11. } else{
12.    // 从 HTTP 头中取得 csrftoken
13.    String xhrToken = req.getHeader(“csrftoken”);
14.    // 从请求参数中取得 csrftoken
15.    String pToken = req.getParameter(“csrftoken”);
16.    if(sToken != null && xhrToken != null && sToken.equals(xhrToken)){
17.        chain.doFilter(request, response);
18.    }else if(sToken != null && pToken != null && sToken.equals(pToken)){
19.        chain.doFilter(request, response);
20.    }else{
21.        request.getRequestDispatcher(“error.jsp”).forward(request,response);
22.    }
23. }

复制代码

这个Token的值必须是随机生成的，如许它就不会被攻击者猜到，考虑使用Java应用程序的java.security.SecureRandom类来生成足够长的随机标志，替代生成算法包括使用256位BASE64编码哈希，选择这种生成算法的开发职员必须确保在散列数据中使用随机性和唯一性来生成随机标识。通常，开发职员只需为当前会话生成一次Token。在初始生成此Token之后，该值将存储在会话中，并用于每个后续请求，直到会话过期。当最终用户发出请求时，服务器端必须验证请求中Token的存在性和有效性，与会话中找到的Token相比较。假如在请求中找不到Token，大概提供的值与会话中的值不匹配，则应中止请求，应重置Token并将变乱记载为正在进行的潜在CSRF攻击。
分布式校验

在大型网站中，使用Session存储CSRF
Token会带来很大的压力。访问单台服务器session是同一个。但是如今的大型网站中，我们的服务器通常不止一台，可能是几十台甚至几百台之多，甚至多个机房都可能在不同的省份，用户发起的HTTP请求通常要经过像Ngnix之类的负载均衡器之后，再路由到具体的服务器上，由于Session默认存储在单机服务器内存中，因此在分布式情况下同一个用户发送的多次HTTP请求可能会先后落到不同的服务器上，导致后面发起的HTTP请求无法拿到之前的HTTP请求存储在服务器中的Session数据，从而使得Session机制在分布式情况下失效，因此在分布式集群中CSRF
Token需要存储在Redis之类的公共存储空间。
由于使用Session存储，读取和验证CSRF Token会引起比较大的复杂度和性能题目，现在很多网站采用Encrypted Token
Pattern方式。这种方法的Token是一个计算出来的结果，而非随机生成的字符串。如许在校验时无需再去读取存储的Token，只用再次计算一次即可。
这种Token的值通常是使用UserID、时间戳和随机数，通过加密的方法生成。如许既可以包管分布式服务的Token一致，又能包管Token不容易被破解。
在token解密乐成之后，服务器可以访问解析值，Token中包含的UserID和时间戳将会被拿来被验证有效性，将UserID与当前登录的UserID进行比较，并将时间戳与当前时间进行比较。
总结

Token是一个比较有效的CSRF防护方法，只要页面没有XSS漏洞泄漏Token，那么接口的CSRF攻击就无法乐成。
但是此方法的实现比较复杂，需要给每一个页面都写入Token（前端无法使用纯静态页面），每一个Form及Ajax请求都携带这个Token，后端对每一个接口都进行校验，并包管页面Token及请求Token一致。这就使得这个防护计谋不能在通用的拦截上统一拦截处理，而需要每一个页面和接口都添加对应的输出和校验。这种方法工作量巨大，且有可能遗漏。
   验证码和密码其实也可以起到CSRF 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：

1. 复制代码Set-Cookie: foo=1; Samesite=Strict
2. Set-Cookie: bar=2; Samesite=Lax
3. Set-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：

1. 复制代码Set-Cookie: foo=1; Samesite=Strict
2. Set-Cookie: bar=2; Samesite=Lax
3. Set-Cookie: baz=3

复制代码

当用户从 a.com 点击链接进入 b.com 时，foo 这个 Cookie 不会被包含在 Cookie 请求头中，但 bar 和 baz
会，也就是说用户在不同网站之间通过链接跳转是不受影响了。但假如这个请求是从 a.com 发起的对 b.com 的异步请求，大概页面跳转是通过表单的 post
提交触发的，则bar也不会发送。
生成Token放到Cookie中而且设置Cookie的Samesite，Java代码如下：

1. 复制代码 private void addTokenCookieAndHeader(HttpServletRequest httpRequest, HttpServletResponse httpResponse) {
2.         //生成token
3.         String sToken = this.generateToken();
4.         //手动添加Cookie实现支持“Samesite=strict”
5.         //Cookie添加双重验证
6.         String CookieSpec = String.format("%s=%s; Path=%s; HttpOnly; Samesite=Strict", this.determineCookieName(httpRequest), sToken, httpRequest.getRequestURI());
7.         httpResponse.addHeader("Set-Cookie", CookieSpec);
8.         httpResponse.setHeader(CSRF_TOKEN_NAME, token);
9.     }

复制代码

我们应该如何使用SamesiteCookie

假如SamesiteCookie被设置为Strict，欣赏器在任何跨域请求中都不会携带Cookie，新标签重新打开也不携带，以是说CSRF攻击基本没有机会。
但是跳转子域名大概是新标签重新打开刚登岸的网站，之前的Cookie都不会存在。尤其是有登录的网站，那么我们新打开一个标签进入，大概跳转到子域名的网站，都需要重新登录。对于用户来讲，可能体验不会很好。
假如SamesiteCookie被设置为Lax，那么其他网站通过页面跳转过来的时候可以使用Cookie，可以保障外域毗连打开页面时用户的登录状态。但相应的，其安全性也比较低。
另外一个题目是Samesite的兼容性不是很好，现阶段除了从新版Chrome和Firefox支持以外，Safari以及iOS
Safari都还不支持，现阶段看来暂时还不能遍及。
而且，SamesiteCookie现在有一个致命的缺陷：不支持子域。例如，种在topic.a.com下的Cookie，并不能使用a.com下莳植的SamesiteCookie。这就导致了当我们网站有多个子域名时，不能使用SamesiteCookie在主域名存储用户登录信息。每个子域名都需要用户重新登录一次。
总之，SamesiteCookie是一个可能替代同源验证的方案，但现在还并不成熟，其应用场景有待观望。
防止网站被使用

前面所说的，都是被攻击的网站如何做好防护。而非防止攻击的发生，CSRF的攻击可以来自：

• 攻击者本身的网站。
  
• 有文件上传漏洞的网站。
  
• 第三方论坛等用户内容。
  
• 被攻击网站本身的品评功能等。
  

对于来自黑客本身的网站，我们无法防护。但对其他情况，那么如何防止本身的网站被使用成为攻击的源头呢？

• 严酷管理所有的上传接口，防止任何预期之外的上传内容（例如HTML）。
  
• 添加Header X-Content-Type-Options: nosniff 防止黑客上传HTML内容的资源（例如图片）被解析为网页。
  
• 对于用户上传的图片，进行转存大概校验。不要直接使用用户填写的图片链接。
  
• 当前用户打开其他用户填写的链接时，需告知风险（这也是很多论坛不答应直接在内容中发布外域链接的原因之一，不仅仅是为了用户留存，也有安全考虑）。
  

CSRF其他防范步伐

对于一线的程序员同砚，我们可以通过各种防护计谋来防御CSRF，对于QA、SRE、安全负责人等同砚，我们可以做哪些变乱来提拔安全性呢？
CSRF测试

CSRFTester是一款CSRF漏洞的测试工具，CSRFTester工具的测试原理大概是如许的，使用署理抓取我们在欣赏器中访问过的所有的毗连以及所有的表单等信息，通过在CSRFTester中修改相应的表单等信息，重新提交，相当于一次伪造客户端请求，假如修改后的测试请求乐成被网站服务器接受，则说明存在CSRF漏洞，固然此款工具也可以被用来进行CSRF攻击。CSRFTester使用方法大抵分下面几个步调：

• 步调1：设置欣赏器署理
  

CSRFTester默认使用Localhost上的端口8008作为其署理，假如署理设置乐成，CSRFTester将为您的欣赏器生成的所有后续HTTP请求生成调试消息。

• 步调2：使用合法账户访问网站开始测试
  

我们需要找到一个我们想要为CSRF测试的特定业务Web页面。找到此页面后，选择CSRFTester中的“开始录制”按钮并实行业务功能；完成后，点击CSRFTester中的“停止录制”按钮；正常情况下，该软件会全部遍历一遍当前页面的所有请求。

• 步调3：通过CSRF修改并伪造请求
  

之后，我们会发现软件上有一系列跑出来的记载请求，这些都是我们的欣赏器在实行业务功能时生成的所有GET大概POST请求。通过选择列表中的某一行，我们如今可以修改用于实行业务功能的参数，可以通过点击对应的请求修改query和form的参数。当修改完所有我们盼望诱导用户form最终的提交值，可以选择开始生成HTML陈诉。

• 步调4：拿到结果如有漏洞进行修复
  

首先必须选择“陈诉范例”。陈诉范例决定了我们盼望受害者欣赏器如何提交先前记载的请求。现在有5种可能的陈诉：表单、iFrame、IMG、XHR和链接。一旦选择了陈诉范例，我们可以选择在欣赏器中启动新生成的陈诉，最后根据陈诉的情况进行对应的排查和修复。
CSRF监控

对于一个比较复杂的网站系统，某些项目、页面、接口漏掉了CSRF防护步伐是很可能的。
一旦发生了CSRF攻击，我们如何及时的发现这些攻击呢？
CSRF攻击有着比较明显的特性：

• 跨域请求。
  
• GET范例请求Header的MIME范例大概率为图片，而实际返回Header的MIME范例为Text、JSON、HTML。
  

我们可以在网站的署理层监控所有的接口请求，假如请求符合上面的特性，就可以认为请求有CSRF攻击猜疑。我们可以提示对应的页面和项目负责人，查抄大概
Review其CSRF防护计谋。
个人用户CSRF安全的发起

经常上网的个人用户，可以采用以下方法来掩护本身：

• 使用网页版邮件的欣赏邮件大概新闻也会带来额外的风险，因为检察邮件大概新闻消息有可能导致恶意代码的攻击。
  
• 尽量不要打开可疑的链接，一定要打开时，使用不常用的欣赏器。
  

总结

简单总结一下上文的防护计谋：

• CSRF主动防御计谋：同源检测（Origin 和 Referer 验证）。
  
• CSRF主动防御步伐：Token验证 大概 双重Cookie验证 以及配合Samesite Cookie。
  
• 包管页面的幂等性，后端接口不要在GET页面中做用户操作。
  

为了更好的防御CSRF，最佳实践应该是结合上面总结的防御步伐方式中的优缺点来综合考虑，结合当前Web应用程序自身的情况做合适的选择，才华更好的预防CSRF的发生。
历史案例

WordPress的CSRF漏洞

2012年3月份，WordPress发现了一个CSRF漏洞，影响了WordPress
3.3.1版本，WordPress是众所周知的博客平台，该漏洞可以答应攻击者修改某个Post的标题，添加管理权限用户以及操作用户账户，包括但不限于删除品评、修改头像等等。具体的列表如下:

• Add Admin/User
  
• Delete Admin/User
  
• Approve comment
  
• Unapprove comment
  
• Delete comment
  
• Change background image
  
• Insert custom header image
  
• Change site title
  
• Change administrator’s email
  
• Change Wordpress Address
  
• Change Site Address
  

那么这个漏洞实际上就是攻击者引导用户先进入目标的WordPress，然后点击其垂纶站点上的某个按钮，该按钮实际上是表单提交按钮，其会触发表单的提交工作，添加某个具有管理员权限的用户，实现的码如下：

1. 复制代码<html>
2. <body onload="javascript:document.forms[0].submit()">
3. <H2>CSRF Exploit to add Administrator</H2>
4. <form method="POST" name="form0" action="http://<wordpress_ip>:80/wp-admin/user-new.php">
5. <input type="hidden" name="action" value="createuser"/>
6. <input type="hidden" name="_wpnonce_create-user" value="<sniffed_value>"/>
7. <input type="hidden" name="_wp_http_referer" value="%2Fwordpress%2Fwp-admin%2Fuser-new.php"/>
8. <input type="hidden" name="user_login" value="admin2"/>
9. <input type="hidden" name="email" value="admin2@admin.com"/>
10. <input type="hidden" name="first_name" value="admin2@admin.com"/>
11. <input type="hidden" name="last_name" value=""/>
12. <input type="hidden" name="url" value=""/>
13. <input type="hidden" name="pass1" value="password"/>
14. <input type="hidden" name="pass2" value="password"/>
15. <input type="hidden" name="role" value="administrator"/>
16. <input type="hidden" name="createuser" value="Add+New+User+"/>
17. </form>
18. </body>
19. </html>

复制代码

YouTube的CSRF漏洞

2008年，有安全研究职员发现，YouTube上几乎所有效户可以操作的动作都存在CSRF漏洞。假如攻击者已经将视频添加到用户的“Favorites”，那么他就能将他本身添加到用户的“Friend”大概“Family”列表，以用户的身份发送恣意的消息，将视频标志为不宜的，主动通过用户的联系人来共享一个视频。例如，要把视频添加到用户的“Favorites”，攻击者只需在任何站点上嵌入如下所示的IMG标签：

1. 复制代码<img src="http://youtube.com/watch_ajax?action_add_favorite_playlist=1&video_
2. id=[VIDEO ID]&playlist_id=&add_to_favorite=1&show=1&button=AddvideoasFavorite"/>

复制代码

攻击者大概已经使用了该漏洞来提高视频的流行度。例如，将一个视频添加到足够多用户的“Favorites”，YouTube就会把该视频作为“Top
Favorites”来显示。除提高一个视频的流行度之外，攻击者还可以导致用户在绝不知情的情况下将一个视频标志为“不宜的”，从而导致YouTube删除该视频。
这些攻击还可能已被用于侵犯用户隐私。YouTube答应用户只让朋友或亲属观看某些视频。这些攻击会导致攻击者将其添加为一个用户的“Friend”或“Family”列表，如许他们就能够访问所有本来只限于好友和亲属表中的用户观看的私家的视频。
攻击者还可以通过用户的所有联系人名单（“Friends”、“Family”等等）来共享一个视频，“共享”就意味着发送一个视频的链接给他们，固然还可以选择附加消息。这条消息中的链接已经并不是真正意义上的视频链接，而是一个具有攻击性的网站链接，用户很有可能会点击这个链接，这便使得该种攻击能够进行病毒式的传播。
黑客 &网络安全如何学习

今天只要你给我的文章点赞，我私藏的网安学习资料一样免费共享给你们，来看看有哪些东西。
1.学习路线图

攻击和防守要学的东西也不少，具体要学的东西我都写在了上面的路线图，假如你能学完它们，你去就业和接私活完全没有题目。
2.视频教程

网上虽然也有很多的学习资源，但基本上都残缺不全的，这是我本身录的网安视频教程，上面路线图的每一个知识点，我都有配套的视频讲解。
内容涵盖了网络安全法学习、网络安全运营等保测评、渗透测试基础、漏洞详解、计算机基础知识等，都是网络安全入门必知必会的学习内容。
3.技术文档和电子书

技术文档也是我本身整理的，包括我到场大型网安举措、CTF和挖SRC漏洞的经验和技术要点，电子书也有200多本，由于内容的敏感性，我就不一一展示了。
4.工具包、口试题和源码

“工欲善其事必先利其器”我为各人总结出了最受欢迎的几十款款黑客工具。涉及范围主要会合在
信息收集、Android黑客工具、主动化工具、网络垂纶等，感兴趣的同砚不容错过。
另有我视频里讲的案例源码和对应的工具包，需要的话也可以拿走。
这些题目都是各人在口试笃佩服、奇安信、腾讯大概其它大厂口试时经常碰到的，假如各人有好的题目大概好的看法欢迎分享。
参考解析：笃佩服官网、奇安信官网、Freebuf、csdn等
内容特点：条理清楚，含图像化表示更加易懂。
内容概要：包括
内网、操作系统、协议、渗透测试、安服、漏洞、注入、XSS、CSRF、SSRF、文件上传、文件下载、文件包含、XXE、逻辑漏洞、工具、SQLmap、NMAP、BP、MSF…
![img](https://img-
blog.csdnimg.cn/img_convert/da1274937756ef025cecc0439519a3d4.png)
因篇幅有限，仅展示部分资料，假如你对网络安全入门感兴趣，需要的话可以在下方
![](https://img-
blog.csdnimg.cn/img_convert/40827b849025375539c64360b039dd6d.png)
题外话

初入计算机行业的人大概大学计算机相关专业毕业生，很多因缺少实战经验，就业到处碰壁。下面我们来看两组数据：
2023届天下高校毕业生预计到达1158万人，就业形势严肃；
国家网络安全宣传周公布的数据显示，到2027年我国网络安全职员缺口将达327万。
一方面是每年应届毕业生就业形势严肃，一方面是网络安全人才百万缺口。
6月9日，麦可思研究2023年版就业蓝皮书（包括《2023年中国本科生就业陈诉》《2023年中国高职生就业陈诉》）正式发布。
2022届大学毕业生月收入较高的前10个专业
本科计算机类、高职主动化类专业月收入较高。2022届本科计算机类、高职主动化类专业月收入分别为6863元、5339元。此中，本科计算机类专业起薪与2021届基本持平，高职主动化类月收入增长明显，2022届反超铁道运输类专业（5295元）排在第一位。
具体看专业，2022届本科月收入较高的专业是信息安全（7579元）。对比2018届，电子科学与技术、主动化等与人工智能相关的本科专业表现不俗，较五年前起薪涨幅均到达了19%。数据科学与大数据技术虽是近年新增专业但表现亮眼，已跻身2022届本科毕业生毕业半年后月收入较高专业前三。五年前唯一进入本科高薪榜前10的人文社科类专业——法语已退出前10之列。

“没有网络安全就没有国家安全”。当前，网络安全已被提拔到国家战略的高度，成为影响国家安全、社会稳定至关重要的因素之一。
网络安全行业特点

1、就业薪资非常高，涨薪快 2022年猎聘网发布网络安全行业就业薪资行业最高人均33.77万！

2、人才缺口大，就业机会多

2019年9月18日《中华人民共和国中央人民政府》官方网站发表：我国网络空间安全人才 需求140万人，而天下各大学校每年造就的职员不到1.5W人。猎聘网《2021年上半年网络安全陈诉》推测2027年网安人才需求300W，如今从事网络安全行业的从业职员只有10W人。

行业发展空间大，岗位非常多
网络安全行业产业以来，随即新增长了几十个网络安全行业岗位︰网络安全专家、网络安全分析师、安全咨询师、网络安全工程师、安全架构师、安全运维工程师、渗透工程师、信息安全管理员、数据安全工程师、网络安全运营工程师、网络安全应急响应工程师、数据鉴定师、网络安全产物经理、网络安全服务工程师、网络安全培训师、网络安全审计员、威胁谍报分析工程师、灾难恢复专业职员、实战攻防专业职员…
职业增值潜力大
网络安全专业具有很强的技术特性，尤其是掌握工作中的焦点网络架构、安全技术，在职业发展上具有不可替代的竞争上风。
随着个人能力的不断提拔，所从事工作的职业价值也会随着自身经验的丰富以及项目运作的成熟，升值空间一路看涨，这也是为什么受各人欢迎的主要原因。
从某种程度来讲，在网络安全领域，跟医生职业一样，越老越吃香，因为技术愈加成熟，自然工作会受到器重，升职加薪则是水到渠成之事。
黑客&网络安全如何学习
今天只要你给我的文章点赞，我私藏的网安学习资料一样免费共享给你们，来看看有哪些东西。
1.学习路线图

行业发展空间大，岗位非常多
网络安全行业产业以来，随即新增长了几十个网络安全行业岗位︰网络安全专家、网络安全分析师、安全咨询师、网络安全工程师、安全架构师、安全运维工程师、渗透工程师、信息安全管理员、数据安全工程师、网络安全运营工程师、网络安全应急响应工程师、数据鉴定师、网络安全产物经理、网络安全服务工程师、网络安全培训师、网络安全审计员、威胁谍报分析工程师、灾难恢复专业职员、实战攻防专业职员…
职业增值潜力大
网络安全专业具有很强的技术特性，尤其是掌握工作中的焦点网络架构、安全技术，在职业发展上具有不可替代的竞争上风。
随着个人能力的不断提拔，所从事工作的职业价值也会随着自身经验的丰富以及项目运作的成熟，升值空间一路看涨，这也是为什么受各人欢迎的主要原因。
从某种程度来讲，在网络安全领域，跟医生职业一样，越老越吃香，因为技术愈加成熟，自然工作会受到器重，升职加薪则是水到渠成之事。
黑客&网络安全如何学习
今天只要你给我的文章点赞，我私藏的网安学习资料一样免费共享给你们，来看看有哪些东西。
1.学习路线图

攻击和防守要学的东西也不少，具体要学的东西我都写在了上面的路线图，假如你能学完它们，你去就业和接私活完全没有题目。
2.视频教程

网上虽然也有很多的学习资源，但基本上都残缺不全的，这是我本身录的网安视频教程，上面路线图的每一个知识点，我都有配套的视频讲解。
内容涵盖了网络安全法学习、网络安全运营等保测评、渗透测试基础、漏洞详解、计算机基础知识等，都是网络安全入门必知必会的学习内容。
3.技术文档和电子书

技术文档也是我本身整理的，包括我到场大型网安举措、CTF和挖SRC漏洞的经验和技术要点，电子书也有200多本，由于内容的敏感性，我就不一一展示了。
4.工具包、口试题和源码

“工欲善其事必先利其器”我为各人总结出了最受欢迎的几十款款黑客工具。涉及范围主要会合在 信息收集、Android黑客工具、主动化工具、网络垂纶等，感兴趣的同砚不容错过。
另有我视频里讲的案例源码和对应的工具包，需要的话也可以拿走。
这些题目都是各人在口试笃佩服、奇安信、腾讯大概其它大厂口试时经常碰到的，假如各人有好的题目大概好的看法欢迎分享。
参考解析：笃佩服官网、奇安信官网、Freebuf、csdn等
内容特点：条理清楚，含图像化表示更加易懂。
内容概要：包括 内网、操作系统、协议、渗透测试、安服、漏洞、注入、XSS、CSRF、SSRF、文件上传、文件下载、文件包含、XXE、逻辑漏洞、工具、SQLmap、NMAP、BP、MSF…

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取
假如你对网络安全入门感兴趣，那么你需要的话可以点击这里