The video player got modified in bug 439358 to allow videos to be specified via the URL. However, there appears to be no restriction as to the source of the videos. This affects mozilla.com and mozilla-europe.org. https://stage.mozilla-europe.org/js/video/playerWithControls.swf?flv=http://www.micropipes.com/temp/superflytnt.flv https://www.authstage.mozilla.com/en-US/firefox/video/playerWithControls.swf?flv=http://www.micropipes.com/temp/superflytnt.flv
I've got a question into the flash developer about white-listing the domains for videos.
Why is this blocking? Because someone can make the mozilla.com site show a video from somewhere else? I agree that it's critical and needs to be fixed, but does it need to be before we put the content up?
(In reply to comment #2) > Why is this blocking? Because someone can make the mozilla.com site show a > video from somewhere else? I agree that it's critical and needs to be fixed, > but does it need to be before we put the content up? > You asked for nominations of bugs on mozilla.com; it's your call. Personally if we get it fixed tomorrow I don't think it's a blocker (it'd be on the live site for a few hours).
OK, I just wanted to make sure I wasn't missing anything. I don't think it's a blocker either, but we should definitely try to get a fix in tomorrow even after launch.
Flags: blocking-firefox3? → blocking-firefox3-
Reed points out that this is basically an XSS hole which could be arbitrarily exploitable, which is more than just hosting random video content. It needs to be fixed, even if we do some sort of preprocessing of our own.
Flags: blocking-firefox3- → blocking-firefox3+
What's the best way to get this fixed by tomorrow? That is, how do we patch this up well enough to keep everything working until the full-time fix is implemented? Steven and I have been working with the Royal Order on this (complicated slightly by the fact that their Flash guy who originally worked on this is out of town), so I'm confident we'll get it fixed soon, but obviously we should have a plan in place to hold us until then.
Super-super-super temp fix added for www.mozilla.com. mozilla-europe.org still needs fixing. Sending .htaccess Transmitting file data . Committed revision 15841.
Assignee: nobody → reed
We have a copy of the .swf file that is hard-coded to look for the one local .fla video, which would fix this. However, we needed the more flexible version for the localized versions which play video hosted on videos.mozilla.org.
Marking FIXED. Please file a follow up for a less-hacky fix. :)
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Hi guys, So after reading thru this thread I’m understanding the issue is the fact that the flv variable in the embed code is passing the URL itself? If so, we can have flv=english or flv=europe, etc. and then have a background processing page on Mozilla’s end that defines what english and europe are equal to which would then process which language video URL to use for the Flash file. If that sounds like a good suggestion I guess next steps would be to create a processing page with all languages needed and to send that to me so I can implement and test in my environment.
Sorry, also forgot to mention I'm the Flash Developer at Royal Order.
Component: www.mozilla.org/firefox → www.mozilla.org
Product: Websites → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.