Re: [WEB SECURITY] countermeasure against attacks through HTML shared files

[Bil Corry <bil@xxxxxxxxx>]

fcorella@xxxxxxxxxx wrote on 11/8/2008 4:00 PM: 
> 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

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.


> 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.


> 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.


- Bil


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA