4

Google Chrome is probably one of the stricter browsers out there in terms of highlighting SSL errors.

Most browsers will point out when you are viewing an HTTPS page which loads insecure images/Javascript, I understand how this is a security issue - an attacker could have modified the non-SSL content in a way which gives them access to the secure content, injected some javascript for example.

However once you have viewed an HTTPS page with mixed content, Google Chrome will continue showing you the mixed content warning (a red line through the 'https://') for as long as you stay browsing the same domain, even for subsequent pages which only include other HTTPS resources. Only once you navigate to another domain, or open a fresh tab does it tell you you're secure again.

What is the danger it's protecting you from here? How could mixed content on a previous page actually affect the security of subsequent secured pages? I understand that mixed content should be flagged up, but there must be a specific reason that Google is persisting this warning, other than "Well you still need to know about it"

| improve this question | |
3

The biggest problem in using mixed content is, that (without preventing it explicitely) cookies are sent to both requests. That means, a session cookie which should be used with a secure HTTPS connection, will be sent also to an unsecure HTTP page request, or even for a request of a picture.

If an attacker can read this session cookie, he can access the site with the same priviledges as you do (if you are logged in, he is logged in as well). It doesn't help that you are switching back to HTTPS only, because the session is already hijacked.

| improve this answer | |
  • That's a good point, I'd not considered access to cookie-based session IDs. I'll run some tests with HTTPOnly cookies (which aren't available to javascript) and see if that holds. However, if this is the reason, Chrome seems to be inconsistent in its behaviour, because closing a tab and reopening it clears the "taintedness" of the session, whereas the problem you describe would still exist. – Gareth Jan 25 '12 at 13:46
  • @Gareth - I'm curious about the result of your test with HTTP-only cookies. Is there a difference, and did the browser keep the session after closing the tab (if the session cookie was deleted automatically, the next call would be safe again)? – martinstoeckli Jan 25 '12 at 14:39
  • I'll post the results when I get some time to test it, but Chrome definitely keeps the session cookie for longer than any individual tab is open - until the whole browser is quit as far as I know – Gareth Jan 25 '12 at 14:47
  • @Gareth - I misread your first comment, testing HTTP-only cookies won't solve the problem, what could help is to use HTTPS-only cookies. – martinstoeckli Jan 26 '12 at 7:47
  • Setting a secure-only session ID cookie will mean that the application simply won't work if there's a need to switch between secure and non-secure pages. I was talking about owasp.org/index.php/HttpOnly – Gareth Jan 26 '12 at 10:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.