full-disclosure - Re: Chrome and Safari users open to stealth HTML5 Application Cache attack

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikuAwzxEV6-SEqQnTdWZ7rtRsI69jvgy-_RPPah@mail.gmail.com>
Date: Mon, 28 Jun 2010 17:53:14 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: Dan Kaminsky <dan@...para.com>
Cc: Lavakumar Kuppan <lava@...labs.org>, full-disclosure@...ts.grok.org.uk
Subject: Re: Chrome and Safari users open to stealth HTML5
	Application Cache attack

> On unsecured networks, attackers could stealthily
> create malicious Application Caches in the browser of victims for even HTTPS
> sites. It has always been possible to poison the browser cache and
> compromise the victim's account for HTTP based sites.
> With HTML5 Application Cache, it is possible to poison the cache of even
> HTTPS sites.
> ==
>
> Is it agreed that if the above is true -- meaning, separation doesn't
> actually exist -- then there's a bug?

My understanding is that this refers to the ability to poison
http://www.mybank.com - which may be the default destination for a
good percentage of users - even if the only function of this page is
to redirect directly to https://www.mybank.com.

There should be no ability to use cache manifests delivered over http
to inject content into the https origin, or at least I hope so.

/mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/