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

[fcorella () pomcor com]

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