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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Sat, 08 Nov 2008 22:00:36 +0000
From: fcorella@...cor.com
To: websecurity@...appsec.org, bugtraq@...urityfocus.com
Subject: Re: [WEB SECURITY] countermeasure against attacks through HTML 
    shared files

Hi Bil,

> > My motivation for deleting the file retrieval
> > session record was that the extended hostname is
> > recorded in the browser history.  So if the user
> > neglects to log out, and is using a laptop, and
> > the laptop is stolen (even if turned off), the
> > thief can access the file from the history until
> > the login session times out.
> 
> Is the thought that once downloaded, the user is storing the file
>  securely on the hard drive?  If not, then I think the attacker will simply
>  lift the file off the laptop rather than trying to re-download the file
>  again.

Well, the user could have deleted the file.  But
you're right, the file is likely to be in the
stolen laptop.  If the browser displayed the file
and the user takes no precautions, the file should
be in the browser's cache.  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.
The stolen laptop scenario was an afterthought.
(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.)  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.

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.

Francisco