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]嵌入跨域内容的能力：

• <script>
  <脚本>
• <link>
  <链接>
• <img>
  <img>
• <video>
  <视频>
• <audio>
  <音频>
• <object>
  <对象>
• <embed>
  <嵌入>
• <applet>
  <小程序>
• <frame>
  <框架>
• <iframe>
  <iframe>

It’s important to note that while cross-origin resources can be freely downloaded and embedded using these tags, javascript running in the browser cannot access or read the contents, save high-level information like image dimensions, actions performed by a script, etc.

重要的是要注意，尽管可以使用这些标记自由下载和嵌入跨域资源，但是运行在浏览器中的javascript无法访问或读取内容，无法保存高级信息，例如图像尺寸，脚本执行的操作等。

It’s also important to note that when embedding these resources, you’re instructing the browser to make HTTP(S) GET requests.

同样重要的是要注意，在嵌入这些资源时，您是在指示浏览器发出HTTP(S)GET请求。

While the following look’s strange, your browser would execute the GET request without restriction.

尽管以下外观很奇怪，但您的浏览器将无限制地执行GET请求。

<img src=”https://dashboard.example.com/post-message/hello">

<img src =” https://dashboard.example.com/post-message/hello“>

It’s irrelevant whether the response is a valid image — the request is still executed. This is why it’s important that state-changing endpoints on your web application cannot be invoked with the GET method.

响应是否为有效图像无关紧要-请求仍在执行。 这就是为什么不能使用GET方法调用Web应用程序上状态更改端点的原因很重要。

好的，因此浏览器可以发出不受限制的GET请求。 我将确保所有状态更改请求只能由POST之类的其他方法调用。 根据SOP，我很安全，对吗？ (Okay, so the browser can make unrestricted GET requests. I’ll just make sure that all of my state-changing requests can only be invoked by other methods like POST. Under the SOP, I’m safe, right?)

Unfortunately, it’s not that simple.

不幸的是，这并不是那么简单。

There are also ways to execute POST requests without restriction by the SOP. These request formulations are where the most damage is done by CSRF.

还有不受SOP限制的执行POST请求的方法。 这些要求的表述是CSRF造成最大损害的地方。

Via the <form> tag, modern browsers that implement the SOP still allow cross-origin POST submit actions. An intricate CSRF attack could, for example, use javascript to create a hidden <form>, populate its fields, and auto-submit, effectively sending an authenticated cross-origin POST request. This is bad news, as POST is one of the standard methods for state-changing actions.

通过<form>标记，实现SOP的现代浏览器仍允许跨域POST提交操作。 例如，复杂的CSRF攻击可以使用javascript创建隐藏的<form>，填充其字段，然后自动提交，从而有效地发送经过身份验证的跨域POST请求。 这是个坏消息，因为POST是状态更改动作的标准方法之一。

But why in the world does the modern web infrastructure allow such madness?

但是，为什么在世界范围内，现代的网络基础架构却可以让这种疯狂呢？

A likely explanation is that to deprecate this functionality would mean lots of breaking changes to the millions of web applications deployed globally. This functionality is a legacy feature that will likely not be changed in the name of backwards compatibility.

一个可能的解释是，不赞成使用此功能将意味着对全球部署的数百万个Web应用程序进行重大更改。 此功能是一项旧功能，可能不会以向后兼容的名义更改。

那么，这些跨源POST <form>请求可以利用到什么程度？ (So to what degree can these cross-origin POST <form> requests be exploited?)

It turns out that there are limits to the formulation of the request itself. To highlight a few:

事实证明，请求本身的表述是有限度的。 要强调一些：

• You cannot set custom headers
  您无法设置自定义标题
• The Content-Type header is limited to one of the following values:
  Content-Type标头限制为以下值之一：

1. application/x-www-form-urlencoded
   应用程序/ x-www-form-urlencoded
2. multipart/form-data
   多部分/表单数据
3. text/plain
   文字/纯文字

因此，使用<form>是提交不受限制的跨域POST请求的唯一方法吗？ (So using a <form> is the only way to submit unrestricted cross-origin POST requests?)

Unfortunately, it’s yet-again not that simple.

不幸的是，它仍然不是那么简单。

Certain unrestricted cross-origin requests can also be formulated using XHR/fetch. All requests can in fact be classified into 1 of 2 bins: “simple” and not “simple” [4]. Cross-origin “simple” requests can be freely sent under the SOP.

某些不受限制的跨域请求也可以使用XHR / fetch来制定。 实际上，所有请求都可以分为2个bin中的1个：“简单”而不是“简单” [4]。 跨域“简单”请求可以在SOP下自由发送。

A “simple” request is one that meets the following conditions:

“简单”请求是满足以下条件的请求：

• The method must be either GET, HEAD, or POST
  该方法必须是GET，HEAD或POST
• Only the following headers can be set manually:
  只能手动设置以下标题：

1. Accept
   接受
2. Accept-Language
   接受语言
3. Content-Language
   内容语言
4. Content-Type*
   内容类型*
5. DPR
   DPR
6. Downlink
   下行链接
7. Save-Data
   保存数据
8. Viewport-Width
   视口宽度
9. Width
   宽度

• *For the Content-Type header, there are only 3 allowed values:
  *对于Content-Type标头，只有3个允许的值：

1. application/x-www-form-urlencoded
   应用程序/ x-www-form-urlencoded
2. multipart/form-data
   多部分/表单数据
3. text/plan
   文字/计划

• For XMLHttpRequestUpload objects, no event listeners can be registered
  对于XMLHttpRequestUpload对象，不能注册任何事件侦听器
• The request cannot use a ReadableStream object
  该请求不能使用ReadableStream对象

It’s interesting to note that the cross-origin requests allowed by various HTML tags are a strict subset of these “simple” requests.

有趣的是，各种HTML标记允许的跨域请求是这些“简单”请求的严格子集。

哇，要花很多钱。因此，浏览器可以执行任何这些“简单”请求，而不受SOP的限制吗？ (Wow, that’s a lot to take in. So the browser can execute any of these “simple” requests without restriction by the SOP?)

Yes, with one distinction:

是的，有一个区别：

Unless Cross-Origin Resource Sharing (CORS) is configured, javascript running in the browser will not be able to read the response. Again, it’s important to take note: These cross-origin “simple” requests are still successfully executed.

除非配置跨域资源共享(CORS)，否则在浏览器中运行的javascript将无法读取响应。 同样，请务必注意：这些跨域“简单”请求仍然可以成功执行 。

那么，当尝试发出一个不是“简单”的请求时会发生什么？ (So what happens when attempting to make a request that isn’t “simple”?)

At last, this is where the SOP comes to the rescue!

最后，这是SOP救援的地方！

In this scenario, before making the request, the browser will send a “preflight” request to the target resource URI. A preflight request uses the OPTIONS method and allows the server to respond with a whitelist of allowed actions. This whitelist is used by the browser to determine if the request is allowed. If the request oversteps its bounds, the browser will block the request. It won’t be sent. Plain and simple.

在这种情况下，在发出请求之前，浏览器将向目标资源URI发送一个“预检”请求。 预检请求使用OPTIONS方法，并允许服务器以允许的操作白名单进行响应。 浏览器使用此白名单来确定是否允许该请求。 如果请求超出其范围，浏览器将阻止该请求。 它不会被发送。 干净利落。

The whitelist of allowed actions is called a Cross-Origin Resource Sharing (CORS) policy. CORS lets web application developers deliberately and intentionally relax certain constraints of the SOP. This is important because making “non-simple” cross-origin requests are still an important functionality of many web applications.

允许的动作的白名单称为跨域资源共享(CORS)策略。 CORS使Web应用程序开发人员有意有意地放宽SOP的某些限制。 这很重要，因为发出“非简单”跨域请求仍然是许多Web应用程序的重要功能。

因此，为了防止CSRF攻击，仅要求我的所有端点仅接受“非简单”请求就足够了(并让飞行前响应禁止所有跨域调用)吗？ (So to prevent CSRF attacks, is it sufficient to require all my endpoints to only accept “non-simple” requests (and let the preflight response disallow all cross-origin invocations)?)

This question hints at a suite of CSRF prevention techniques that don’t depend on CSRF tokens. The techniques can be summarized as follows:

这个问题暗示了一套不依赖CSRF令牌的CSRF预防技术。 这些技术可以总结如下：

• Require all backend endpoints to accept only “non-simple” requests.
  要求所有后端端点仅接受“非简单”请求。
• When incoming requests are “simple” (i.e. they don’t overstep the conditions outlined above), let the server simply reject them.
  当传入的请求是“简单的”(即它们不会超出上述条件)时，让服务器简单地拒绝它们。
• Carefully Configure your CORS policy to never allow cross-origin requests that aren’t “simple”.
  仔细配置您的CORS策略，以禁止不“简单”的跨域请求。

An example technique that falls into this suite would be a web application server whose endpoints require the presence of a Content-Type header with the value, application/json.

属于此套件的一种示例技术是Web应用程序服务器，其端点要求存在带有值application / json的Content-Type标头。

这样就足够了吗？ (So is this sufficient?)

Yes, in theory.

是的， 理论上 。

But in practice, this is not always the case. Ugh, more caveats!

但实际上 ，情况并非总是如此。 gh，更多警告！

To assume protection from CSRF by requiring only “non-simple” requests is to trust the browsers’ implementation of very nuanced details of the Same Origin Policy. As others have pointed out, historically there have been various bugs and loopholes that have allowed hackers to bypass preflight for “non-simple” requests [5]. Prominent examples include a vulnerability in Flash that allowed for non-standard headers to bypass preflight, and a bug in Chrome’s Navigator.sendBeacon API which allowed for non-standard values in the Content-Type header to bypass preflight [6,7].

通过仅要求“非简单”请求来承担免受CSRF的攻击的保护，就是相信浏览器对“同源起源策略”非常细微细节的实现。 正如其他人指出的那样，从历史上看，存在各种漏洞和漏洞，这些漏洞和漏洞使黑客能够绕过“非简单”请求的预检[5]。 突出的示例包括Flash中的一个漏洞，该漏洞允许非标准标头绕过预检，而Chrome的Navigator.sendBeacon API中的一个错误允许Content-Type标头中的非标准值绕过预检[6,7]。

There are arguments for why certain CSRF-prevention techniques that force requests to be “non-simple” are not sufficient enough to prevent CSRF (e.g. the bugs and loopholes referenced above). But even the arguments in favor of CSRF Tokens, however, depend on the proper implementation of the SOP (i.e. not allowing read-access to the response of a cross-origin request). So from the many points of view, we are all placing trust in our friends who are implementing modern browsers to adhere to the SOP. Web security in general requires faith and trust in a lot of different people, institutions, hardware, and software.

对于为什么某些强制请求“非简单”的CSRF预防技术不足以阻止CSRF(例如，上面提到的错误和漏洞)，存在争议。 但是，即使支持CSRF令牌的参数也取决于SOP的正确实现(即，不允许对跨域请求的响应进行读取访问)。 因此，从许多角度来看，我们都信任正在实施现代浏览器以遵守SOP的朋友。 通常，Web安全要求对许多不同的人员，机构，硬件和软件具有信念和信任。

结论 (Conclusion)

If there are only a few things I hope you take away from this post, they’re these:

如果只有几件事我希望您能从这篇文章中删除，那就是这些：

• Even when the Same Origin Policy is implemented perfectly as documented, there are still subtleties that allow for certain authenticated cross-origin requests to be executed, including GET and POST. As defined above, all “simple” requests fall under this category.
  即使完全按照记录实施了同源起源策略，仍然存在一些微妙之处，可以执行某些经过身份验证的跨域请求，包括GET和POST。 如上所述，所有“简单”请求都属于此类别。
• Various protection techniques, including the popular CSRF Token or the rejecting of all “simple” requests, still depend on the SOP to be implemented as documented.
  各种保护技术(包括流行的CSRF令牌或拒绝所有“简单”请求)仍然取决于要按文档所述实施的SOP。

• CSRF is a very serious attack vector that requires attention by web application developers.

  CSRF是一种非常严重的攻击媒介， 需要 Web应用程序开发人员注意 。

At Posh, we are bringing modern Conversational AI to the forefront. Our mission is to make natural conversation the new user interface.

在Posh，我们将现代会话式AI推到了最前沿。 我们的任务是使新的用户界面自然对话。