Re: Badly behaved captive portals

Lanyrd uses Twitter for logins, but we don't redirect there, we
provide a login link for the user to click. We never wanted to do
login redirects, but yeah, appcache means we can't. Gmail DOES 302 to
another domain for logins, so yes, we should add this as a use-case.

As for security, we should make it not-a-problem by avoiding creating
any new security considerations, but we shouldn't deal with existing
security issues.

If you're on a network that can make a captive portal redirect, they
can also inject content into HTTP responses (cookies, ads). Appcache
may exacerbate the issue by persisting it, but the 'attacker' can
already do something very similar with the standard cache. This isn't
a new issue & the solution is HTTPS.

> 1) if I had a proxy/controller type thing, I'd be able to inspect the response, see it was not what I expected, and fish something out of localstorage instead.

Hmmm, this creates a new security issue. Imagine you visit my evil website...

1. You hit my page, it sets up an appcache proxy controller thing
2. window.reload()
3. My evil server knows this is your 2nd visit & redirects to gmail,
all-your-passwords.com, whatever
4. It falls into the proxy, I can inspect the response, reading your
emails/passwords

Obviously we could restrict what you can get from the response, maybe
even just to the target url, but we'd have to be very careful not to
create a new cross-domain access vector.

Received on Sunday, 23 September 2012 13:05:04 UTC