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屋！