跨站请求伪造已经死了！(译文)

在Web上使用Cross-Site Request Forgery进行劳作之后，我们终于有了一个合适的解决方案。 没有网站所有者的技术负担，没有困难的实施，部署简单，它是Same-Site Cookies。

与Web本身一样古老

跨站请求伪造，也称为CSRF或XSRF，基本上永远存在。 它源于网站必须向另一个站点发出请求的简单功能。 假设我在此页面中嵌入了以下表单。

<form action="https://your-bank.com/transfer" method="POST" id="stealMoney">
<input type="hidden" name="to" value="Scott Helme">
<input type="hidden" name="account" value="14278935">
<input type="hidden" name="amount" value="£1,000"> 

您的浏览器加载此页面，结果是上面的表单，然后我在页面上使用一个简单的JS提交。

document.getElementById("stealMoney").submit(); 

这就是CSRF的名称来源。 我正在伪造一个跨站点发送请求到您的银行。 这里真正的问题不是我发送了请求，而是您的浏览器会发送您的cookie。 该请求将把您当前持有的全部权限一并发送，这意味着如果您已登录到您的银行，您就需向我捐赠1,000英镑， 谢谢！ 如果您没有登录，那么请求将是无害的，因为您无法在未登录的情况下转账。目前，您的银行可以通过几种方式来缓解这些CSRF攻击。

CSRF缓解措施

我不会详细说明这些，因为网上有大量有关此主题的信息，但我想快速介绍它们以显示实施它们的技术要求。

检查来源(Origin)

在服务端收到请求时，会向我们提供Origin头和Referer头来说明请求的来源。 您可以检查其中的一个或两个值，以查看请求是否源自不同的来源。 如果是跨域请求，则只需将其丢弃即可。 Origin和Referer头确实得到了一些防止浏览器的保护，以防止被篡改，但它们可能并不总是存在。

accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
accept-encoding: gzip, deflate, br
cache-control: max-age=0
content-length: 166
content-type: application/x-www-form-urlencoded
dnt: 1
origin: https://report-uri.io
referer: https://report-uri.io/login
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 

Anti-CSRF令牌

您可以使用两种不同的方式使用Anti-CSRF令牌，但原则保持不变。当访问者请求页面时，如上例中的转移金额页面，您将随机令牌嵌入到表单中。当真正的用户提交此表单时，将返回随机令牌，您可以检查它是否与您在表单中发出的令牌相匹配。在CSRF攻击情形中，攻击者永远无法获得此值，即使他们请求页面也无法获取此值，因为同源策略（SOP）会阻止攻击者读取包含令牌的响应。此方法运行良好，但要求站点跟踪Anti-CSRF令牌的发布和返回。类似的方法是将令牌嵌入到表单中，并向浏览器发出包含相同值的cookie。当真正的用户提交他们的表单时，cookie中的值和表单将在网站收到时匹配。当攻击者发送伪造请求时，浏览器将不会设置CSRF cookie，测试将失败。

<form action="https://report-uri.io/login/auth" method="POST"><input type="hidden" name="csrf_token" value="d82c90fc4a14b01224gde6ddebc23bf0"><input type="email" id="email" name="email"><input type="password" id="password" name="password"><button type="submit" class="btn btn-primary">Login</button>
</form> 

问题

上述方法长期为我们提供了相当强大的CSRF保护。 检查Origin和Referer头不是100%可靠，并且大多数站点采用Anti-CSRF令牌方法的一些变体。 问题是，这些都对网站提出了某种要求来实施和维护解决方案。 它们可能不是世界上技术最复杂的东西，但我们仍然在构建一个解决方案，围绕浏览器做一些我们不希望它做的事情。 相反，为什么我们不告诉浏览器停止做我们不希望它做的事情？…现在我们可以！

Same-Site Cookies

您可能已经在我最近的一篇名为Tough Cookies的博客中看到过Same-Site Cookies，但我将在这里通过一些例子更深入地介绍它。 从本质上讲，Same-Site Cookies完全有效地抵消了CSRF攻击。Dead. Finito. Adios! 捕获我们在网络上真正需要的本质以赢得安全战，Same-Site Cookies易于部署，非常简单。 拿你现有的cookie：

Set-Cookie: sess=abc123; path=/ 

只需添加SameSite属性即可。

Set-Cookie: sess=abc123; path=/; SameSite=lax 

你完成了。 说真的，就是这样！ 在cookie上启用此属性将指示浏览器为此cookie提供某些保护。 有两种模式可以在Strict或Lax中启用此保护，具体取决于您想要获得的严重程度。

SameSite=Strict
SameSite=Lax 

Strict 严格模式

将SameSite保护设置为严格模式显然是首选，但我们有两个选择的原因是并非所有站点都相同，也没有相同的要求。当在严格模式下操作时，浏览器根本不会在任何跨源请求上发送cookie，因此CSRF完全死在水中。您可能遇到的唯一问题是它也不会在顶级导航上发送cookie（更改地址栏中的URL）。如果我提供了https://facebook.com的链接，并且Facebook将SameSite cookie设置为严格模式，当您单击链接到打开Facebook时，您将无法登录。无论您是否已登录，在新标签页中打开它，无论您做什么，从该链接访问时都不会登录到Facebook。这对用户来说可能有点烦人和/或意外，但确实提供了令人难以置信的强大保护。 Facebook在这里需要做的是类似于亚马逊做的，他们有2个cookie。一种是一种“基本”cookie，可以将您识别为用户，并允许您拥有登录体验，但如果您想做一些敏感的事情，比如购买或更改帐户中的内容，则需要第二个cookie， “真正的”cookie，可以让你做重要的事情。在这种情况下，第一个cookie不会设置SameSite属性，因为它是一个“方便”的cookie，它实际上不允许你做任何敏感的事情，如果攻击者可以用它做出跨域请求，则没有任何反应。但是，第二个cookie（敏感cookie）将设置SameSite属性，攻击者就不能滥用权限到跨源请求中。这是用户和安全性的理想解决方案。但这并不总是可行的，因为我们希望SameSite cookie易于部署，这里还有第二种选择。

Lax 松散模式

将SameSite保护设置为Lax模式可以修复上述用户点击链接的严格模式中提到的问题，如果他们已经登录，则不会在目标站点上登录。在Lax模式下，只有一个例外允许cookie附加到使用安全HTTP方法的顶级导航。 “安全”HTTP方法在RFC 7321第4.2.1节中定义为GET，HEAD，OPTIONS和TRACE，我们对此处的GET方法感兴趣。 这意味着，当用户单击链接时，我们对https://facebook.com的顶级导航现在在浏览器发出请求时附加了SameSite标记的cookie，从而保持了预期的用户体验。 我们还完全受到基于POST的CSRF攻击的保护。 回到顶部的示例，此攻击仍然无法在Lax模式下工作。

<form action="https://your-bank.com/transfer" method="POST" id="stealMoney">
<input type="hidden" name="to" value="Scott Helme">
<input type="hidden" name="account" value="14278935">
<input type="hidden" name="amount" value="£1,000"> 

由于POST方法不被认为是安全的，因此浏览器不会在请求中附加cookie。 攻击者当然可以自由地将方法更改为“安全”方法并发出相同的请求。

<form action="https://your-bank.com/transfer" method="GET" id="stealMoney">
<input type="hidden" name="to" value="Scott Helme">
<input type="hidden" name="account" value="14278935">
<input type="hidden" name="amount" value="£1,000"> 

只要我们不接受GET请求代替POST请求，那么这种攻击是不可能的，但是在Lax模式下操作时需要注意。 此外，如果攻击者可以触发顶级导航或弹出新窗口，他们还可以使浏览器发出附加了cookie的GET请求。 这是在Lax模式下运营的权衡，我们保持用户体验不变，但也有较小的风险接受付款。

其他用途

此博客旨在使用SameSite Cookie缓解CSRF，但正如您可能已经猜到的那样，此机制也有其他用途。 规范中列出的第一个是跨站点脚本包含（XSSI），浏览器在此处请求资源，例如脚本，该脚本将根据用户是否经过身份验证而更改。 在跨站点请求方案中，攻击者不能滥用SameSite Cookie的环境权限来产生不同的响应。 此处详细介绍了一些有趣的计时攻击，那可以有效缓解滥用情况。

另一个不详细的有趣用途是防止在BEAST式压缩攻击（CRIME，BREACH，HEIST，TIME）中泄露会话cookie的价值。 这是非常高级别的，但基本情况是MiTM可以强制浏览器通过他们喜欢的任何机制发出跨源请求并监视它们。 通过滥用请求有效负载大小的变化，攻击者可以通过改变浏览器发出的请求并在线路上观察它们的大小，一次一个字节地猜测会话ID值。 使用SameSite Cookies，浏览器不会在此类请求中包含cookie，因此攻击者无法猜测其值。

浏览器支持

随着浏览器中大多数新的安全功能，您可以期望Firefox或Chrome的领导这项功能，这里的情况也不例外。 自v51以来，Chrome已经支持Same-Site Cookies，这意味着Android上的Opera，Android浏览器和Chrome也有支持。 您可以在caniuse.com上查看列出当前支持的详细信息，Firefox也有一个bug，可以添加支持。 尽管支持尚未普及，但我们仍应将SameSite属性添加到cookie中。 理解它的浏览器将尊重设置并提供cookie额外的保护，而那些不理解它的人将完全忽略它并继续前行。 这里没有什么可失去的，它形成了一个非常好的防御深度方法。 我们可以考虑删除传统的反CSRF机制，但是在这些机制之上添加SameSite会给我们带来难以置信的强大防御。

原文：scotthelme.co.uk/csrf-is-dea… 原文发布日期：2017年2月20日 作者：Scott Helme 译者：帕奇式

翻译及转载获得作者许可：

学习网络安全技术的方法无非三种:

第一种是报网络安全专业，现在叫网络空间安全专业，主要专业课程:程序设计、计算机组成原理原理、数据结构、操作系统原理、数据库系统、 计算机网络、人工智能、自然语言处理、社会计算、网络安全法律法规、网络安全、内容安全、数字取证、机器学习，多媒体技术，信息检索、舆情分析等。

第二种是自学，就是在网上找资源、找教程，或者是想办法认识一-些大佬，抱紧大腿，不过这种方法很耗时间，而且学习没有规划，可能很长一段时间感觉自己没有进步，容易劝退。

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！

第三种就是去找培训。

接下来，我会教你零基础入门快速入门上手网络安全。

网络安全入门到底是先学编程还是先学计算机基础？这是一个争议比较大的问题，有的人会建议先学编程，而有的人会建议先学计算机基础，其实这都是要学的。而且这些对学习网络安全来说非常重要。但是对于完全零基础的人来说又或者急于转行的人来说，学习编程或者计算机基础对他们来说都有一定的难度，并且花费时间太长。

第一阶段：基础准备 4周~6周

这个阶段是所有准备进入安全行业必学的部分，俗话说：基础不劳，地动山摇

第二阶段：web渗透

学习基础 时间：1周 ~ 2周：

① 了解基本概念：（SQL注入、XSS、上传、CSRF、一句话木马、等）为之后的WEB渗透测试打下基础。
② 查看一些论坛的一些Web渗透，学一学案例的思路，每一个站点都不一样，所以思路是主要的。
③ 学会提问的艺术，如果遇到不懂得要善于提问。

配置渗透环境 时间：3周 ~ 4周：

① 了解渗透测试常用的工具，例如（AWVS、SQLMAP、NMAP、BURP、中国菜刀等）。
② 下载这些工具无后门版本并且安装到计算机上。
③ 了解这些工具的使用场景，懂得基本的使用，推荐在Google上查找。

渗透实战操作 时间：约6周：

① 在网上搜索渗透实战案例，深入了解SQL注入、文件上传、解析漏洞等在实战中的使用。
② 自己搭建漏洞环境测试，推荐DWVA，SQLi-labs，Upload-labs，bWAPP。
③ 懂得渗透测试的阶段，每一个阶段需要做那些动作：例如PTES渗透测试执行标准。
④ 深入研究手工SQL注入，寻找绕过waf的方法，制作自己的脚本。
⑤ 研究文件上传的原理，如何进行截断、双重后缀欺骗(IIS、PHP)、解析漏洞利用（IIS、Nignix、Apache）等，参照：上传攻击框架。
⑥ 了解XSS形成原理和种类，在DWVA中进行实践，使用一个含有XSS漏洞的cms，安装安全狗等进行测试。
⑦ 了解一句话木马，并尝试编写过狗一句话。
⑧ 研究在Windows和Linux下的提升权限，Google关键词：提权

以上就是入门阶段

第三阶段：进阶

已经入门并且找到工作之后又该怎么进阶？详情看下图

给新手小白的入门建议：
新手入门学习最好还是从视频入手进行学习，视频的浅显易懂相比起晦涩的文字而言更容易吸收，这里我给大家准备了一套网络安全从入门到精通的视频学习资料包免费领取哦！

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！