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.

Improve this question
4
  • How does the video feed work? Commented Apr 12, 2011 at 15:55
  • The video feed comes through a flash player being served from another server (ustream's watershed) Commented Apr 12, 2011 at 15:59
  • If you're loading an unencrypted SWF, you are very vulnerable. Commented Apr 12, 2011 at 16:00
  • I hope you realize that you're trusted the remote site. Commented Apr 12, 2011 at 22:03

2 Answers 2

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

11 Comments

So... if the flash embed/object is pointing to an unecrypted flash file, then I'm completely vulnerable?
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.
code.google.com/p/doctype/wiki/ArticleFlashSecuritySolutions You could add <param name="allowScriptAccess" value="never"> <param name="allowNetworking" value="none"> <param name="swliveconnect" value="false">, but you'll still be vulnerable to SWF's compiled against older versions.
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?
Yes, but to version 7, not 8.
|
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.

Improve this answer

4 Comments

You're right; I had assumed that everything was on a different domain. (He said outside source)
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...
I assume that he realizes that he must trust the other site.
@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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.