4 ms·
Could somebody help me understand how this attack would be viable? It seems like the attack has the following requirements: 1. You want a secret that appear
by STRML 13y ago
Could somebody help me understand how this attack would be viable?
It seems like the attack has the following requirements:
1. You want a secret that appears in the response body, like a
CSRF token.
2. The web server always responds with the exact same response
for a request.
3. The response body contains data that you send to the server,
e.g. url params.
4. The attacker has access to an environment where he can send requests
under your browser session (otherwise, the user would be
unauthenticated and there would be no secrets to steal).
Given (4.), how is this a real concern? If I, an attacker, am able to make 3000+ requests while logged in under your session and modify the request character by character pre-encryption, doesn't it logically follow that I have your cookies anyway?
- Erwin 13y agoThe #4 is not that difficult without compromising the user's browser -- as long as the user can visit the site under your command or see some HTML under your commend you can make the browser do a HTTPS request to anywhere at all. Maybe you buy some targetted ads served in an iframe. Maybe you send the user an email where his email server either always shows images, or you trick the user in clicking 'display images' with promise of kittens. You won't be able to see the results directly, but if you can observe how long the encrypted responses will be, you'll know whether your reflected input could make use of the compression dictionary (meaning your reflected input matches the secret) or not. I wonder if there is any way to even do this without the passive network snooping -- like some kind of internal browser stats API call that tells you # of HTTPS bytes transferred. It could be innocent enough so it's not protected.
- tptacek 13y agoNo, it does not logically follow. The attack means that someone who can (for instance) poison the DNS can (for instance) evade CSRF protection for the domains they've poisoned.