When a page delivers secure and non-secure items o

问题:

I'm not 100% sure that I'm using the correct terminology or if I'm leaving out information that is required to answer. So please be patient with me.

My client wants to include a video feed from an outside source inside a members area of their website. The members area is delivered over https and the video feed is not. Does this compromise the secure data?

I know that some browsers alert the user that there are secure and non-secure data being loaded on the page. Frankly, my client is okay with that, but I don't want to move forward if the user account information (specifically, session, etc.) is compromised.

Thanks for any help.

回答1:

If your pages references unencrypted Javascript or Flash, you're totally unprotected; an attacker can substitute any Javascript he wants, and can steal non-HTTP-only cookies, or make arbitrary HTTP requests that impersonate the current user.

If you reference unencrypted CSS, you're still vulnerable; attackers can arbitrarily modify your layout, and can execute arbitrary code in IE and Firefox.

If you reference unencrypted images, you're mostly fine; all the attacker can do is see the Referer header and find out what page the user is seeing. (He'll also get any non-SSL-only cookies for the image's domain). The attacker can also alter the images to suit his needs, which may be a concern.

回答2:

If you identify your user based on a cookie, e.g. using a standard SessionId, then you are vulnerable, even if only referencing static images.

By default, the user's browser will resend the session cookie for each request to the same host, irrelevant of protocol. I.e. you securely authenticated your user using HTTPS on your login form, and ensure to continue using HTTPS for all sensitive pages...
However, you also include "non-sensitive" images over HTTP... the user's browser will happily send the sensitive session cookie over non-encrypted, non-secure, plain-text HTTP, when requesting those images.
Then it's just a matter of grabbing that cookie from HTTP, and impersonating your users back on the secure part of the site.

Note, this is by default. You CAN change this behavior, by adding the secure; attribute to your cookies. Depending on your framework, you can configure it to happen automatically. Again, this is not the default, you have to explicitly change it.
And while you're at it, add the httpOnly; attribute too.