【问题标题】:a real CSRF attack?真正的 CSRF 攻击?
【发布时间】:2013-08-15 17:31:37
【问题描述】:

我们团队最近讨论了 CSRF 攻击。我的团队成员说以下是 CSRF 攻击: 1. 攻击者向受害者发送一个伪造的html文件,该文件可能有一些伪造的请求,如窃取cookie 2.受害者保存文件 3.受害者打开受信任的网站,然后打开html文件 4.文件的请求被执行

它可以在允许用户注销的情况下工作。以下是脚本:

<!DOCTYPE html>
<html>
<body>

<p>Create a link of an image:
<a href="default.asp">
<img src="smiley.gif" alt="HTML tutorial" width="32" height="32"></a></p>

<p>No border around the image, but still a link:
<a href="https://chaseonline.chase.com/secure/LogOff.aspx">
<img border="0" src="smiley.gif" alt="HTML tutorial" width="32" height="32"></a></p>

</body>
</html>

至少可以让自己成功下线。但是,我觉得这是因为该文件是在本地执行的,这使它工作。如果我打开一个真正的恶意网站或页面,它可能无法正常工作。谁能给我任何想法?

谢谢~

【问题讨论】:

    标签: security web-applications csrf


    【解决方案1】:

    让我也举一个 CSRF 攻击的经典例子,攻击者诱骗受害者将钱转移到他的账户,前提是受害者与银行有一个活跃的会话。这种攻击需要在受害者与银行进行合法会话时代表受害者提交 POST 请求。攻击者可以让受害者访问包含以下 HTML 的页面:

    <html>
    <body>
          <form name="hack_form" action="http://CrapyBank.com/csrf.php?menu=400&TransferFunds=4000" method="POST">
              <input type="hidden" name="hack_param" value="hack">
          </form>
          <script type="text/javascript">document.hack_form.submit();</script>
    </body>
    </html>
    

    【讨论】:

      【解决方案2】:

      好的,假设您为一家银行经营一个网站。假设您有一个端点,它接受POSThttps://bank.example.com/transfer 的请求,其中包含要转移到的帐户和要转移的金额的表单数据。当然,您将检查会话 cookie 以确保请求来自具有有效会话的用户。

      现在,恶意网站可以构建一个表单,其中包含他们希望向其汇款的帐号和任意金额的金额。现在他们需要做的就是将恶意站点的所有访问者发布到https://bank.example.com/transfer。任何在登录您的银行网站(并获得有效的会话 cookie)后登陆恶意网站的受害者,现在都可以从他们那里窃取资金。

      此攻击的标准修复方法是要求所有导致重要状态更改的端点也提交一个随机的一次性密钥,该密钥与用户的 cookie 缓存分开(通常包括您的网站在页面上)您希望请求来自)。

      【讨论】:

        猜你喜欢
        • 2013-05-06
        • 2011-09-30
        • 2020-02-16
        • 2019-04-25
        • 2019-08-19
        • 2020-05-27
        • 2018-03-05
        • 2016-01-30
        • 1970-01-01
        相关资源
        最近更新 更多