Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Chrome and Safari users open to stealth HTML5 Application Cache attack
From: Lavakumar Kuppan <lava () andlabs org>
Date: Mon, 28 Jun 2010 22:28:21 +0530

Hi Chris,

Excellent points. Please find my answers inline.

It's an interesting twist but it does not seem to offer network
attackers any additional advantage beyond what they can already

The real advantage is in the lifetime of the cache.
If the root resource of www.andlabs.org is cached, the moment the user hits
the refresh button this cache would be cleared.
Because the browser would make a request to the server and for the root page
the response would be a 200.
However a cache created with the Application Cache can survive this and can
till the user explicitly clears the cache.

Having said that, the claim that HTTPS sites can only be compromised using
Application Cache is inaccurate, thanks for pointing it out. I will update
the post to highlight this.

In terms of your documented attack, the fake login page (step 6) is
shown over plain HTTP, i.e. the SSL lock icon will be missing. This
would be the same user experience as if the user were under attack via

That is correct and I had mentioned SSLstrip in the post as well.
The big advantage is that for SSLstrip to work they have to access that site
when on the unsecured network.
Where as with cache poisoning, they only have to open their browsers as even
the request sent for the default home page can be used to create these
malicious caches.
The actual attacks happens when the users are on trusted network and they
are more likely to ignore this as they would feel safe then.

(FWIW, Chromium resolves this for me. When I type mail<enter> into
the omnibar, it auto-completes to https://mail.google.com/

This happens because you might have typed in 'https://mail.google.com/&apos;
earlier in your browser.
If you only access gmail by typing in gmail.com then Chrome does not
auto-complete to the https equivalent.
At least that has been my experience.


On Sun, Jun 27, 2010 at 3:28 PM, Lavakumar Kuppan <lava () andlabs org>
Google Chrome and Safari support HTML5 Application Cache.
But unlike Firefox and Opera they do not ask for user permission before
allowing a site to create an Application Cache.
On unsecured networks, attackers could stealthily
create malicious Application Caches in the browser of victims for even
It has always been possible to poison the browser cache and compromise
victim's account for HTTP based sites.
With HTML5 Application Cache, it is possible to poison the cache of even
HTTPS sites.
I have also released a POC using which both Facebook and Gmail can be
POC - http://www.andlabs.org/tools/imposter/imposter_poc.zip
Video - http://www.youtube.com/watch?v=00sKMMyXJsI


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

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]