通过 GET 请求抵御 CSRF 攻击的安全性?

问题描述

我已经在我的网络服务器上构建了一个无状态的、基于 JWT 的用户身份验证系统，遵循 Stormpath 的例子(https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage).

这个设置对于 CSRF 来说似乎非常安全，但我想知道 GET 请求怎么样.

通过在来自不同域的页面上包含 标记，我能够对 GET 请求的 CSRF 攻击进行建模.服务器使用状态为 200 的整页响应请求.虽然我没有更改 GET 请求的任何数据，但页面可能仍包含一些敏感信息，例如，<img src="https://example.com/account"/>可能会给出用户的详细信息，或者 <img src="https://example.com/logout"/> 可以简单地做一些烦人的事情，我认为可以有更多的例子.

这个 攻击是否被认为是无害的，因为浏览器不会公开它得到的响应?是否有任何其他滥用 HTML 标签的技巧可能通过将服务器输出显示给 GET 请求而导致泄露敏感信息?

我正在考虑将我的 JWT 访问令牌的哈希值额外包含到 GET URL 中，并让服务器要求 GET 请求包含该哈希值，并且它必须与 cookie 中的 JWT 令牌匹配.这样，攻击者将无法猜测有效的 GET URL，同时泄露此类 GET URL 将不允许攻击者访问我的服务器，因为他不知道来自 cookie 的原始 JWT.除了轻微的可用性问题外，这个设置对我来说似乎是个好主意，但我没有在谷歌上搜索过类似的东西，所以我很怀疑 :)

解决方案

CSRF 攻击的概念，它强制经过身份验证的用户对其授权的 Web 应用程序执行不需要的操作.

CSRF 攻击确保为无状态服务器引入状态更改，不涉及窃取数据，因为 GET 请求会将响应获取给受害者而不是攻击者，因为受害者已获得授权.攻击者无法看到对伪造请求的响应.

CSRF 攻击可以带来服务器状态的变化，但看不到结果，只能盲目行动.

比方说，CSRF 攻击可以告诉受害者浏览器请求受害者银行帐户余额，但攻击者看不到该余额.这显然是毫无意义的攻击.

但是，如果攻击者要求受害者浏览器执行从受害者帐户到攻击者帐户的资金转移，也并非毫无意义.攻击脚本无法访问传输的成功或失败页面.攻击者不关心成功或失败的反应，他主要关心的是他想要账户里的钱.

如果您正在执行 GET 请求以更改服务器的状态，那么您可能会面临风险.

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1"，如果您的请求是这样的话.

我认为不会.

因此，您必须关注 POST 请求，该请求应使用 CSRF 令牌进行监控.

分享 OWASP 规则的链接 https://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_%28CSRF%29 必须去一次.

I've built a stateless, JWT-based user authentication system on my web server, following the example of Stormpath (https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage).

The setup seems pretty secure against CSRF, but I'm wondering what about the GET requests.

I was able to model a CSRF attack on GET request by including an <img> tag on a page from a different domain. The server responds to the request with a full page with 200 status. While I don't change any data on GET requests, the pages may still contain some sensitive information, for example, <img src="https://example.com/account" /> may give out user's details, and or <img src="https://example.com/logout" /> could simply do something annoying, and I think there can be more examples.

Is this <img> attack considered harmless, because the browser will not disclose the repsonse it gets? Are there any other tricks with abusing HTML tags that could lead to disclosure of sensitive information by revealing the server output to a GET request?

I'm thinking to additionally include a hash of my JWT access token to the GET URL and have the server require that GET requests include that hash, and it must match the JWT token from the cookie. In this way the attacker will not be able to guess a valid GET URL, while also leaking such GET URL will not allow the attacker to get access to my server because he doesn't know the original JWT from cookies. Apart from minor usability issues, this setup looks like a good idea to me, but I haven't googled out anything similar, so I'm suspicious :)

解决方案

​Concept of CSRF attack, it forces the authenticated user to perform unwanted actions on a web application to which he is authorized to. 

CSRF attacks ensures to introduce the state change for stateless servers, thefting of data is not involved as GET request would fetch the response to the victim not to the attacker, as victim is authorized to. There is no means that attacker can see the response to the forged request. 

A CSRF attack can bring the change to the state of the server but it can't see their results, it is forced to act blindly. 

Let's say, CSRF attack can tell the victim browser to request victim bank account balance, but the attacker can't see that balance. This is obviously a pointless attack.

But it is not pointless if, the attacker ask the victim browser to perform transfer of money from victim account to the attacker's account. The success or failure page for the transfer is inaccessible to the attacking script. Attacker is not concerned about the response of success or failure​, his main concern lies he want money in his account.

If you are performing GET request to change the state of the server, it may turn out to be risky for you.

"GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1", if one such is your request. 

Which I believe it would not be.

So you must focus on POST request which should be monitored using CSRF token. 

Sharing the link for OWASP rules https://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_%28CSRF%29 must go it once.

这篇关于通过 GET 请求抵御 CSRF 攻击的安全性?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！