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]
Message-ID: <W8150927066116191226181636@webmail40>
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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ