重播HTTPS请求的攻击 [英] Replay attacks for HTTPS requests

问题描述

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

Let's say a security tester uses a proxy, say Fiddler, and records an HTTPS request using the administrator's credentials-- on replay of the entire request (including session and auth cookies) the security tester is able to succesfully (re)record transactions. The claim is that this is a sign of a CSRF vulnerability.

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

What would a malicious user have to do to intercept the HTTPS request and replay it? It this a task for script kiddies, well funded military hacking teams or time-traveling-alien technology? Is it really so easy to record the SSL sessions of users and replay them before the tickets expire?

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

No code in the application currently does anything interesting on HTTP GET, so AFAIK, tricking the admin into clicking a link or loading a image with a malicious URL isn't an issue.

推荐答案

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

HTTPS is not replayable, the first server response in the handshake sequence includes a server-chosen random number.

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

What Fiddler does is act as a proxy, meaning it intercepts your browser's requests, and then generates an identical request to the server, meaning it has access to the plaintext, which is what it will be replaying. Your browser lets you know this by telling you the certificate is from Fiddler - "DO_NOT_TRUST_FiddlerRoot", which you have to agree to before it will send the message ignoring the certificate mismatch.

这篇关于重播HTTPS请求的攻击的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！