csrf令牌
by: Matt McEachern, Posh Co-founder and CTO
作者：Posh联合创始人兼CTO Matt McEachern
CSRF, which stands for Cross-Site Request Forgery, is a common attack vector for vulnerable web applications with potentially catastrophic consequences. At number 8 in the 2013 OWASP TOP 10*, CSRF is an age-old attack that has been well-known by both hackers and implementers [1].
CSRF代表“跨站点请求伪造”，它是易受攻击的Web应用程序的常见攻击媒介，具有潜在的灾难性后果。 在2013年OWASP TOP 10 *中排名第8，CSRF是一种古老的攻击，已为黑客和实施者所熟知[1]。
While there is a multitude of accepted prevention techniques, each has its pros and cons. Amongst the most popular and recommended techniques are ones that implement a CSRF Token. The CSRF Token technique requires that all state-changing endpoints accept an additional parameter (i.e. the CSRF Token) whose value was sent alongside the html/css/js of the web application. Upon each request, the web application’s backend server verifies the correctness of this token and rejects the request if it does not correspond to the session. A decent analogy is that while session cookies authenticate the request’s browser, CSRF Tokens authenticate the code that’s making the request. While effective, a downside to the CSRF Token pattern is that it requires stringent developer effort and changes to client-side code.
尽管有许多公认的预防技术，但是每种技术都有其优缺点。 在最流行和推荐的技术中，有一种实现CSRF令牌的技术。 CSRF令牌技术要求所有状态更改端点都接受一个附加参数(即CSRF令牌)，其值与Web应用程序的html / css / js一起发送。 根据每个请求，Web应用程序的后端服务器会验证此令牌的正确性，如果请求与会话不对应，则拒绝该请求。 一个不错的类比是，虽然会话cookie对请求的浏览器进行身份验证，但CSRF令牌对进行请求的代码进行身份验证。 虽然有效，但CSRF令牌模式的不利之处在于，它要求开发人员进行严格的工作并需要更改客户端代码。
Beyond CSRF Tokens, there are many other techniques that aim to thwart CSRF attacks [2]. Each technique depends on certain assumptions of the web application security model, especially the Same Origin Policy (SOP) which is implemented by all modern browsers today.
除CSRF令牌外，还有许多其他技术可以阻止CSRF攻击[2]。 每种技术都取决于Web应用程序安全模型的某些假设，尤其是当今所有现代浏览器都实施的同源起源策略(SOP)。
In this post, I provide a quick summary of CSRF and the SOP, while highlighting a few shortcomings of the SOP in thwarting CSRF attacks. Then, I discuss a suite of prevention techniques that don’t involve CSRF Tokens and bring attention to their pros and cons.
在这篇文章中，我提供了CSRF和SOP的快速摘要，同时重点介绍了SOP在阻止CSRF攻击方面的一些缺点。 然后，我讨论了一套不涉及CSRF代币的预防技术，并关注了它们的优缺点。
*In the updated 2017 OWASP Top 10, CSRF has been “retired, but not forgotten.”
*在更新的2017年OWASP Top 10中，CSRF已“退休，但未被遗忘”。
CSRF快速摘要 (Quick Summary of CSRF)
CSRF is the execution of a “forged” request to a web application's backend server from an unknown origin. The scenario can best be explained by example:
CSRF是从未知来源向Web应用程序的后端服务器执行“伪造”请求。 可以通过示例最好地解释该方案：
Let’s say you just logged into banking.example.com to check your account balances and pay off your credit card. Because you’re logged in, your browser now holds a session cookie for banking.example.com. This cookie gets sent by the browser with every request to banking.example.com’s backend server — otherwise, you’d be logged out if you refreshed the page or closed the browser window.
假设您刚刚登录bank.example.com来检查帐户余额并还清信用卡。 由于您已登录，因此您的浏览器现在拥有一个banking.example.com的会话cookie。 该Cookie随浏览器的每次请求都发送到banking.example.com的后端服务器-否则，如果刷新页面或关闭浏览器窗口，您将被注销。
- In the same browser, you then decide to check your email and see one that’s titled, “Re: Your Google Account May be Compromised.” That seems scary. You think, “Dang, I hope my account is okay!” Your emotions and fear go against your logic, and you open the email. It says, “go to the following link to secure your account.” Instinctively, you click the link without even reading the URL. 然后，在同一浏览器中，您决定检查您的电子邮件，并看到标题为“重新：您的Google帐户可能遭到入侵”的电子邮件。 这似乎很可怕。 您以为，“老兄，我希望我的帐户还可以！” 您的情绪和恐惧违背了您的逻辑，因此您打开了电子邮件。 它说：“转到以下链接以保护您的帐户。” 本能地，您甚至不阅读URL就单击链接。
Your browser proceeds to open the link, which loads an inanimate white page. The URL’s origin is getpwned.example.com. Well, it’s only a white screen, and you think, “that was weird” so you close the tab and go on with your day. Later you find out that your entire checking account balance has been wired to an unknown account in China.
您的浏览器将继续打开链接，该链接将加载无生命的白页。 URL的来源是getpwned.example.com 。 好吧，它只是一个白色的屏幕，您认为“这很奇怪”，因此您关闭了选项卡并继续进行下去。 后来，您发现您的全部支票帐户余额已电汇到中国的一个未知帐户。
What happened? When your browser opened the webpage at getpwned.example.com, it began executing all kinds of nasty javascript code. It turns out this javascript, which was sent amongst the contents of the webpage, made requests to banking.example.com, instructing it to transfer all of your checking account balance to the unknown account. Because your browser was holding cookies for banking.example.com, it’s default behavior was to attach them to each outbound request.
发生了什么？ 当您的浏览器在getpwned.example.com上打开网页时，它开始执行各种讨厌的javascript代码。 事实证明，此javascript是在网页内容中发送的，它向banking.example.com发出了请求，指示其将所有支票帐户余额转移到未知帐户。 因为您的浏览器中包含用于bank.example.com的 cookie，所以默认行为是将它们附加到每个出站请求中。
In summary:
综上所述：
javascript code from getpwned.example.com made fully authenticated requests to banking.example.com, effectively stealing all your money. This is CSRF.
来自getpwned.example.com的javascript代码向banking.example.com进行了完全身份验证的请求，有效地窃取了您的所有资金。 这是CSRF。
In the example, it’s important to note that the victim had to be tricked into visiting the malicious website. This trickery is the result of Social Engineering. Such carefully executed Social Engineering is not always needed to perform CSRF attacks, however. In fact, every single webpage you visit can perform CSRF; surfing the Web requires a lot of trust.
在示例中，必须注意，必须诱骗受害者访问恶意网站。 这是社会工程学的结果。 但是，执行CSRF攻击并不总是需要如此精心执行的社会工程学。 实际上，您访问的每个网页都可以执行CSRF。 上网冲浪需要很多信任。
Fortunately for users like you, security-minded implementers have introduced CSRF preventions into their web applications that would prevent catastrophic scenarios like the one in the banking.example.com example. As mentioned previously, CSRF Tokens are one such prevention technique. Many of these techniques depend on the Same Origin Policy.
幸运的是，对于像您这样的用户，具有安全意识的实施者已在其Web应用程序中引入了CSRF预防措施，这些预防措施可以防止灾难性的情况发生，例如bank.example.com示例中的情况。 如前所述，CSRF令牌就是这样一种预防技术。 这些技术中有许多都依赖于“相同来源策略”。
同源政策 (The Same Origin Policy)
The Same Origin Policy (SOP) is a critical component of the web application security model. It outlines a series of policies and rules for how code and data can interact across origins and is implemented by all modern web browsers.
相同来源策略(SOP)是Web应用程序安全模型的重要组成部分。 它概述了有关代码和数据如何跨源交互的一系列策略和规则，并由所有现代Web浏览器实现。
One of the major goals of the SOP is to prevent malicious websites from accessing sensitive information or making state-changing requests to other web applications. While the SOP has been widely successful at thwarting a Pandora’s Box of problems, there are subtleties that can still leave web applications vulnerable to cross-origin attacks like CSRF, as discussed below.
SOP的主要目标之一是防止恶意网站访问敏感信息或向其他Web应用程序发出状态更改请求。 尽管SOP在克服潘多拉魔盒问题方面已经取得了广泛的成功，但仍然存在一些细微之处，这仍然会使Web应用程序容易遭受跨域攻击，如CSRF，如下所述。
在SOP中放宽限制 (Relaxed Restrictions Within the SOP)
Despite the various rules and restrictions outlined by the SOP, there are certain resource-sharing actions that are unrestricted.
尽管SOP概述了各种规则和限制，但是某些资源共享操作不受限制。
One type of relaxed restriction is the ability to embed cross-origin content via the following HTML tags [3]:
一种宽松的限制类型是通过以下HTML标签[3]嵌入跨域内容的能力：