我在我的网络服务器上建立了一个无状态的，基于JWT的用户身份验证系统，遵循Stormpath（https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage）的例子。
这个设置对CSRF来说似乎很安全，但我想知道GET请求是什么。
我能够通过在来自不同域的页面上包含<img>标记来模拟对GET请求的CSRF攻击。服务器以200状态的整页响应请求。虽然我没有更改GET请求的任何数据，但页面可能仍然包含一些敏感信息，例如，<img src="https://example.com/account" />可能会提供用户的详细信息，或者<img src="https://example.com/logout" />可能只是做一些烦人的事情，而我认为可以有更多的例子。
此<img>攻击是否被视为无害，因为浏览器不会透露它获得的回复？是否有其他滥用HTML标签的技巧，可能会通过向GET请求显示服务器输出来泄露敏感信息？
我想在JET URL中另外包含我的JWT访问令牌的哈希，并让服务器要求GET请求包含该哈希，并且它必须与cookie中的JWT令牌匹配。通过这种方式，攻击者将无法猜测有效的GET URL，同时泄漏此类GET URL也不允许攻击者访问我的服务器，因为他不知道来自cookie的原始JWT。除了轻微的可用性问题，这个设置看起来对我来说是一个好主意，但我没有搜索任何类似的东西，所以我怀疑：）
答案 0 :(得分：4)
CSRF攻击的概念，它强制经过身份验证的用户对其授权的Web应用程序执行不需要的操作。
CSRF攻击确保为无状态服务器引入状态更改，不涉及数据的设置，因为GET请求会向受害者提取响应而不是攻击者，因为受害者有权获得。攻击者无法看到对伪造请求的响应。
CSRF攻击可以带来服务器状态的变化而却看不到自己的结果，就被迫盲目行事。让我们说，CSRF攻击可以告诉受害者浏览器请求受害者银行帐户余额，但攻击者无法看到这种平衡。这显然是无意义的攻击。</ p>
但是，如果攻击者要求受害者浏览器将受害者帐户中的资金转移到攻击者的帐户，则毫无意义。攻击脚本无法访问传输的成功或失败页面。攻击者不关心成功或失败的反应，他主要担心的是他在账户中要钱。
如果您正在执行GET请求以更改服务器的状态，则可能会对您造成风险。
“GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP / 1.1”，如果有这样的请求。
我相信它不会。
因此，您必须关注应使用CSRF令牌监控的POST请求。
分享OWASP规则https://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_%28CSRF%29的链接必须一次。