我的理解是CSRF阻止攻击者使用 <img> 标记让受害者的浏览器发送一个使用会话cookie进行身份验证的请求 . 鉴于 <img> 总是使用GET请求而不是POST提交,那么为什么在POST请求中需要CSRF令牌呢?
<img>
此外,攻击者无法在不能运行代码(即XSS攻击)的情况下在网页中提交表单,在这种情况下,他们无论如何都可以绕过您的CSRF保护 .
攻击者可以在自己的站点上托管表单,但不要求用户提交表单 . 他们可以使用JavaScript来执行此操作:
<form method="post" action="http://www.example.com/executeAction"> <input type="hidden" name="action" value="deleteAllUsers"> </form> <script>document.forms[0].submit()</script>
IFrame注入更多的是一个XSS漏洞 . XSS漏洞比CSRF漏洞更严重,因为可以造成更多损害,并且它将始终覆盖您拥有的任何CSRF保护 . 确保始终正确编码输出所在上下文的输出(例如,编码为HTML或适用于JavaScript) .
查看Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet - 他们最好的建议是使用同步器令牌模式,它似乎与_2777763中的链接类似,但可以与cookie结合使用 .
此外,这里是XSS (Cross Site Scripting) Prevention Cheat Sheet的链接 .
跨站点请求伪造是指一个站点(比如evil.example.com)可以强制访问用户向另一个站点发出请求(例如example.com) . 它并没有真正强迫用户,因为通过表单提交或javascript嵌入图像(HTTP GET请求)或POST请求并不困难 .
您不应通过HTTP GET请求更改状态或数据 . img标签(获取请求)不应该做任何改变 . 如果你允许这个...停止它 . :)
POST请求需要包含远程攻击者无法猜测的值 . 通常,这是每个请求的随机值 .
所以,是的,CSRF是一个已经证明的,已知的漏洞,你应该打扰防范 .
做了一些进一步的调查:
攻击者可能在他们自己的站点上托管 <form> ,该站点提交到目标站点(您的站点) . 他们所需要做的就是让受害者提交此表格,并将提交他们的cookies以及可能的身份验证 .
<form>
攻击者也有可能向您的站点注入一个 <iframe> ,然后就可以显示这个恶意的 <form> .
<iframe>
我认为token-based approach对我的用例来说是更好的解决方案 .
3 回答
攻击者可以在自己的站点上托管表单,但不要求用户提交表单 . 他们可以使用JavaScript来执行此操作:
IFrame注入更多的是一个XSS漏洞 . XSS漏洞比CSRF漏洞更严重,因为可以造成更多损害,并且它将始终覆盖您拥有的任何CSRF保护 . 确保始终正确编码输出所在上下文的输出(例如,编码为HTML或适用于JavaScript) .
查看Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet - 他们最好的建议是使用同步器令牌模式,它似乎与_2777763中的链接类似,但可以与cookie结合使用 .
此外,这里是XSS (Cross Site Scripting) Prevention Cheat Sheet的链接 .
跨站点请求伪造是指一个站点(比如evil.example.com)可以强制访问用户向另一个站点发出请求(例如example.com) . 它并没有真正强迫用户,因为通过表单提交或javascript嵌入图像(HTTP GET请求)或POST请求并不困难 .
您不应通过HTTP GET请求更改状态或数据 . img标签(获取请求)不应该做任何改变 . 如果你允许这个...停止它 . :)
POST请求需要包含远程攻击者无法猜测的值 . 通常,这是每个请求的随机值 .
所以,是的,CSRF是一个已经证明的,已知的漏洞,你应该打扰防范 .
做了一些进一步的调查:
攻击者可能在他们自己的站点上托管
<form>
,该站点提交到目标站点(您的站点) . 他们所需要做的就是让受害者提交此表格,并将提交他们的cookies以及可能的身份验证 .攻击者也有可能向您的站点注入一个
<iframe>
,然后就可以显示这个恶意的<form>
.我认为token-based approach对我的用例来说是更好的解决方案 .