Bugtraq mailing list archives
Re: [WEB SECURITY] countermeasure against attacks through HTML shared files
From: fcorella () pomcor com
Date: Mon, 10 Nov 2008 17:05:38 +0000
Bil,
If the browser displayed the file and the user takes no precautions, the file should be in the browser's cache.Yngve Pettersen of Opera is working on a proposed browser specification for "Context Cache" that would allow cached items to expire/be discarded immediately upon logging out: http://my.opera.com/yngve/blog/2007/02/27/introducing-cache-contexts-or-why-the http://www.ietf.org/internet-drafts/draft-pettersen-cache-context-03.txt
An interesting proposal.
I know he's looking for feedback on the idea. And of course, all the new "stealth" modes being built into browsers would also help (they do have use beyond surfing adult-content).To tell you the truth, the original motivation was just that it's not a good idea to have a valid authentication token (the file retrievel session ID) embedded in a URL.Sure, it can show up in logs, referer, etc. If you don't mind JavaScript, it's easy enough to use JavaScript to submit a POST.There is also a more exotic scenario: the attacker reads the authentication token from the user's computer display, as it is shown in the address box of the browser. These days, with a camera phone, the attacker does not have to be James Bond to pull that off.You could insert as the first param random junk that's 100 characters long that will "push" the real token off-screen.
Yes.
In any case, I do think now that the file retrieval session ID must remain valid while the login session is valid, in case the browser issues multiple requests for the same file.No, the thing to do here is a one-time, limited duration key. When the browser first hits the download page using the key, the user is assigned an internal session by the file download site, and the one-time key is voided. No replay attacks. The internal session is used for all subsequent requests. And the key is limited in duration (maybe a minute), so if the user's browser dies or can't reach the download site, the key expires after the time limit.
Yes, good idea. (I assume that what you mean by "key" is what I called "file retrievel session ID", and the "internal session" is for the purpose of authenticating subsequent request ***for the same file***, and "the user is assigned an internal session by the download site" means that such an internal session record is created on the server side, and a cookie referring to the internal session is set in the user's browser; this cookie would be specific to the file, and it would be used in addition to the cookie that authenticates application pages and the cookie that authenticates standard-URL requests for user files.)
Actually, I think there may be another case where a browser may issue multiple requests (besides the case where a large file download is interrupted), namely to implement sniffing. A browser may download an initial portion of the file to determine its type, and then download the rest. It's not clear to me why a second request would be needed to download the rest, rather than just continuing the download; but I think I remember seeing some version of IE issue a second request, when downloading MS Office documents.Switching from the one-time key to an internal session ID (as described above) solves these issues.
Yes. (Same assumptions.) Thanks! Francisco
Current thread:
- Re: [WEB SECURITY] countermeasure against attacks through HTML shared files fcorella (Nov 07)
- <Possible follow-ups>
- Re: [WEB SECURITY] countermeasure against attacks through HTML shared files fcorella (Nov 09)
- Re: [WEB SECURITY] countermeasure against attacks through HTML shared files fcorella (Nov 11)