csrf跨站请求伪造_保护用户免受跨站请求伪造（CSRF）

csrf跨站请求伪造

Hackers are most likely to succeed in compromising user accounts through exploiting the design of internet protocols. In this article, I would like to focus on a feature of HTTP that has proven to also be a liability: cookies.

黑客最有可能通过利用Internet协议的设计来成功破坏用户帐户。 在本文中，我想着重介绍HTTP的一项已被证明也有责任的功能：cookie。

Cookies可能是一个责任，但它们非常有用 (Cookies can be a liability, but they’re super useful)

Yes, cookies are super useful. Websites extensively utilize cookies for session storage. Once you login to a website, the server dispatches some session cookies that your web browser remembers for a certain period of time. Cookies greatly improve user experience. I mean, can you imagine having to login for every single page navigation on a website?

是的，cookie超级有用。 网站广泛使用cookie进行会话存储。 登录网站后，服务器将分派一些会话cookie，您的网络浏览器会在一段时间内记住这些会话cookie。 Cookies极大地改善了用户体验。 我的意思是，您能想象必须登录网站上的每个页面导航吗？

But their usefulness does come at a security price — they enable one of the most common HTTP attacks that are trivial to carry out: Cross-Site Request Forgery (CSRF). Let’s discuss a hypothetical example to illustrate the danger of CSRF attacks. An imaginary payment processor called PurplePay will be used.

但是，它们的实用性确实是以安全为代价的-它们使最简单的最常见HTTP攻击之一得以执行：跨站点请求伪造(CSRF)。 让我们讨论一个假设的示例，以说明CSRF攻击的危险。 将使用一个称为PurplePay的虚拟支付处理器。

CSRF受害者示例：PurplePay (CSRF Victim Example: PurplePay)

PurplePay is a simple online payment processor that allows you to send money to anyone with a PurplePay account. The screen above is shown after you login on the PurplePay website. That means when you login, PurplePay instructs your browser to store session cookies regarding your successful authentication attempt. Keep this in mind as it is important for later.

PurplePay是一个简单的在线付款处理程序，可让您向使用PurplePay帐户的任何人汇款。 登录PurplePay网站后，将显示上面的屏幕。 这意味着登录时，PurplePay指示浏览器存储有关成功身份验证尝试的会话cookie。 请记住这一点，因为这对于以后很重要。

The developers at PurplePay decided to implement the form shown above as an HTTP POST request that accepts a name and an amount (In US$). If we are to zoom into the form submission and examine its body, it would look something like this:

PurplePay的开发人员决定将上面显示的形式实现为HTTP POST请求，该请求接受名称和金额(美元)。 如果我们要放大表单提交并检查其主体，它将看起来像这样：

POST http://purplepay.com/send-money{
    "name": "Bill Gates",
    "amount": 50
}

As discussed earlier, the browser will automatically insert the session cookies along with the POST method, and PurplePay will use these session cookies to validate that the right person initiated this transaction. This eliminates the possibility that an unauthorized person might perform a transaction. This seems secure enough, right?

如前所述，浏览器将自动将会话cookie和POST方法一起插入，PurplePay将使用这些会话cookie来验证合适的人发起了此交易。 这消除了未经授权的人可能进行交易的可能性。 这似乎足够安全，对吗？

输入：CSRF黑客 (Enter: CSRF Hacker)

A hacker stumbles upon PurplePay, and studies the message format for the purplepay.com/send-money POST request. The hacker realizes that other than session cookies, there is nothing else needed to successfully invoke the send-money resource on the server.

黑客偶然发现了PurplePay，并研究了purplepay.com/send-money POST请求的消息格式。 黑客意识到，除了会话cookie之外，不需要其他任何内容即可成功调用服务器上的send-money资源。

Since PurplePay stores session cookies in the browsers of their users, the hacker realizes he can create a phishing website that can silently submit a POST request to purplepay.com/send-money. Here is a sample page that a hacker can create.

由于PurplePay将会话Cookie存储在其用户的浏览器中，因此黑客意识到他可以创建一个网络钓鱼网站，该网站可以以无提示的方式向purplepay.com/send-money.提交POST请求purplepay.com/send-money. 这是黑客可以创建的示例页面。

The hacked.html page will automatically send a POST request to purplepay.com/send-money when the page loads. When the browser is about the send the POST request, it realizes it has some cookies for PurplePay already, and decides to append them to the request automatically.

该hacked.html页面会自动发送POST请求purplepay.com/send-money在页面加载时。 当浏览器即将发送POST请求时，它意识到它已经具有一些适用于PurplePay的cookie，并决定自动将它们附加到请求中。

Notice anything really bad? If the hacker can convince a user to simply load that webpage, the hacker has gotten access to the user’s PurplePay session cookies automatically. If the session cookies are still valid, then the hacker’s hidden request to purplepay.com/send-money is considered authenticated by PurplePay, and the hacker now has full ability to transfer all money out of the user’s account, without having direct access to it!

注意到有什么不好的吗？ 如果黑客可以说服用户简单地加载该网页，则表明该黑客已自动访问了该用户的PurplePay会话Cookie。 如果会话cookie仍然有效，那么黑客对purplepay.com/send-money的隐藏请求将被PurplePay验证为身份验证，并且黑客现在具有将所有资金从用户帐户中转出的全部功能，而无需直接访问它！

This methodology of forcing a browser to pass along stored cookies, that are used to access restricted resources, is what is known as Cross-Site Request Forgery (CSRF). As you can imagine now, its scale and damage can be catastrophic if not detected and disabled. Bank accounts can be emptied, credit cards stolen, and anything else that you can securely perform online could be compromised.

强制浏览器传递用于访问受限制资源的存储cookie的这种方法称为跨站点请求伪造 (CSRF)。 正如您现在可以想象的那样，如果不检测和禁用它，其规模和破坏可能是灾难性的。 银行帐户可能会被清空，信用卡被盗，并且您可以安全地在线执行的任何其他操作都可能受到损害。

保护自己免受CSRF的侵害 (Protecting yourself from CSRF)

Luckily enough, with some widely accepted mitigation practices, you could continue using cookies for session storage without fearing CSRF attacks. Let’s look into a few of the most popular solutions.

幸运的是，通过一些广泛接受的缓解措施，您可以继续使用cookie进行会话存储，而不必担心CSRF攻击。 让我们研究一些最受欢迎的解决方案。

(反)-CSRF令牌 ((Anti)-CSRF tokens)

Recall that CSRF is possible because the server only checks for the session cookies to authenticate the request. Unfortunately, this has proven to be insecure because the browser automatically passes them on.

回想一下CSRF是可能的，因为服务器仅检查会话cookie以验证请求。 不幸的是，事实证明这是不安全的，因为浏览器会自动将其传递。

A simple and effective solution is the server-side generation of a cryptographic token, contextually named here as CSRF token. The server would pass the token to the client on pages that require form submissions (or any other POST request interactions). It is important that the server does not pass this token as a cookie, or we’re back to the same situation.

一种简单有效的解决方案是在服务器端生成加密令牌，在上下文中在上下文中将其称为CSRF令牌 。 服务器将在需要表单提交(或任何其他POST请求交互)的页面上将令牌传递给客户端。 重要的是，服务器不要将此令牌作为cookie传递，否则我们将回到同样的情况。

The client would then have to present the CSRF token whenever it submits a POST request, usually included as part of the request body. The server validates the CSRF token for authenticity on top of the session cookies.

然后，无论何时客户端提交POST请求(通常包含在请求正文中)，都必须出示CSRF令牌。 服务器在会话cookie之上验证CSRF令牌的真实性。

SameSite饼干 (SameSite Cookies)

Since the emergence of the CSRF attack, web browsers have added security mechanisms like disabling Cross-Origin Site Requests (CORS) altogether. Furthermore, servers can reject requests that can from a different origin.

自CSRF攻击出现以来，Web浏览器已添加了一些安全机制，例如完全禁用跨源站点请求(CORS)。 此外，服务器可以拒绝来自不同来源的请求。

SameSite cookies work along the same tone in combating CSRF attacks. When cookies are created, you can restrict them to being SameSite only, meaning that the browser WILL NOT pass them on if a request is being initiated from a separate origin. This also can provide some security against CSRF attacks.

在打击CSRF攻击时，SameSite Cookie的工作原理相同。 创建cookie时，可以将其限制为SameSite ，这意味着如果请求是从另一个来源发起的，浏览器将不会继续传递它们。 这也可以提供一些针对CSRF攻击的安全性。

If you would like to do more detailed readings, Wikipedia has a great entry on CSRF: https://en.wikipedia.org/wiki/Cross-site_request_forgery

如果您想做更详细的阅读，Wikipedia在CSRF上有很多文章： https : //en.wikipedia.org/wiki/Cross-site_request_forgery

翻译自: https://medium.com/javascript-in-plain-english/protect-your-users-from-cross-site-request-forgery-csrf-8b341b9beea2

csrf跨站请求伪造