我以Stormpath(https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage)为例，在我的Web服务器上构建了基于JWT的无状态用户身份验证系统。
该设置对于CSRF来说似乎很安全，但是我想知道GET请求如何。
通过在来自其他域的页面上包含<img>标记，我能够对GET请求进行CSRF攻击建模。服务器以200状态的整页响应请求。尽管我没有更改GET请求的任何数据，但是页面可能仍然包含一些敏感信息，例如<img src="https://example.com/account" />可能会提供用户详细信息，或者<img src="https://example.com/logout" />可能会令人讨厌，并且我认为可以有更多示例。
这种<img>攻击是否被认为是无害的，因为浏览器不会透露得到的回复？滥用HTML标记是否还有其他技巧，可能会通过向GET请求显示服务器输出来导致敏感信息泄露？
我正在考虑将我的JWT访问 token 的哈希值另外包含到GET URL中，并让服务器要求GET请求包括该哈希值，并且它必须与cookie中的JWT token 匹配。这样，攻击者将无法猜测有效的GET URL，同时泄漏此类GET URL也将使攻击者无法访问我的服务器，因为他不知道cookie中的原始JWT。除了一些小小的可用性问题之外，这种设置对我来说似乎是个好主意，但是我没有用谷歌搜索出类似的东西，所以我很可疑:)
最佳答案
``CSRF攻击的概念是，它强制经过身份验证的用户在其有权访问的Web应用程序上执行不需要的操作。
CSRF攻击确保为无状态服务器引入状态更改，不涉及数据的盗窃，因为GET请求将获取对受害者的响应，而不是对受害者的授权，即对攻击者的响应。攻击者没有任何办法可以看到对伪造请求的响应。
CSRF攻击可以将更改带入服务器状态，但看不到其结果，因此被迫盲目行动。
假设CSRF攻击可以告诉受害者浏览器请求受害者银行帐户余额，但是攻击者看不到该余额。这显然是毫无意义的攻击。
但是，如果攻击者要求受害者浏览器执行从受害者帐户到攻击者帐户的转账，这并不是没有意义的。攻击脚本无法访问传输的成功或失败页面。攻击者并不关心成功或失败的 react ，他主要担心的是他想在自己的账户中存钱。
如果您正在执行GET请求以更改服务器的状态，则可能对您有风险。
如果您的请求是“GET http://bank.com/transfer.do?acct=BOB&amount=100HTTP/1.1”。
我相信不会。
因此，您必须关注应使用CSRF token 监视的POST请求。
共享OWASP规则的链接https://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_%28CSRF%29必须进行一次。