2

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.

quakkels
  • 11,676
  • 24
  • 92
  • 149

2 Answers2

4

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.

Community
  • 1
  • 1
SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • So... if the flash embed/object is pointing to an unecrypted flash file, then I'm completely vulnerable? – quakkels Apr 12 '11 at 16:00
  • Correct. The attacker can substitute an evil SWF that executes sends requests to your server. There may be Flash security options that mitigate this risk. – SLaks Apr 12 '11 at 16:01
  • http://code.google.com/p/doctype/wiki/ArticleFlashSecuritySolutions You could add ` `, but you'll still be vulnerable to SWF's compiled against older versions. – SLaks Apr 12 '11 at 16:03
  • what do you mean 'compiled against older versions'? Are you saying an attacker could compile an swf to version 8 of flash and get around those security precautions? – quakkels Apr 12 '11 at 16:06
  • Yes, but to version 7, not 8. – SLaks Apr 12 '11 at 16:15
  • imo - Flash in general just seems to be a badly executed concept. – quakkels Apr 12 '11 at 16:25
  • apparently... the swf that is being loaded needs script access, networking, etc... :-( – quakkels Apr 12 '11 at 16:31
  • There is a lot of good points here, however you missed the mark on the bottom line re images. See my answer. Also, @quakkels you can also try over at http://security.stackexchange.com/ ... – AviD Apr 12 '11 at 19:34
  • Couldn't an attacker also change the image that's being returned, potentially conning users into following instructions contained in that image? (e.g. "Your computer is at risk! Quick: go to bit.ly/...") – StriplingWarrior Sep 09 '14 at 18:33
  • @StriplingWarrior: Yes; that's why the browser so show a yellow warning triangle if there are insecure images or CSS. – SLaks Sep 09 '14 at 21:34
  • @SLaks: That's what I thought. Perhaps you should qualify the "you're fine" statement in your final paragraph. – StriplingWarrior Sep 09 '14 at 21:57
1

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.

AviD
  • 12,944
  • 7
  • 61
  • 91
  • 1
    You're right; I had assumed that everything was on a different domain. (He said _outside source_) – SLaks Apr 12 '11 at 20:12
  • ohh, hmm... @SLaks you may be right, missed the part about the content being offsite, if that is indeed the case. However, if that is the case, there is a different question, possibly better - about retrieving content from a 3rd party, potentially untrusted site. There are quite a few security issues stemming from that, including offsite ads... – AviD Apr 12 '11 at 20:19
  • I assume that he realizes that he must trust the other site. – SLaks Apr 12 '11 at 20:49
  • @Slaks not necessarily. There are better and worse ways to do so, and he might not realize that in certain cases the all-powerful "Cross-Domain Policy" is not as powerful as most think. – AviD Apr 12 '11 at 21:44