Summary: | [GTK] handle media redirections | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Philippe Normand <pnormand> | ||||||||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | oliver, slomo | ||||||||||
Priority: | P2 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | OS X 10.5 | ||||||||||||
Attachments: |
|
Description
Philippe Normand
2010-01-12 11:01:29 PST
Created attachment 46459 [details]
media redirections support
Comment on attachment 46459 [details]
media redirections support
For security reasons you need to disallow cross-origin redirects from media, otherwise canvas origin security checks may be bypassed
Created attachment 46547 [details]
media redirections support
Comment on attachment 46547 [details]
media redirections support
Okay this origin check stuff looks sane to me, but i'll need to defer to a gtk/gstreamer type person for review proper sorry :(
Looks good in general, some notes: - In MediaPlayerPrivate::loadNextLocation(), new-location could actually be a absolute URI. Simple to check. Also use gst_value_get_structure() as this does type checks. - The redirect message might have a "new-location" field but not "locations" field. The "new-location" field would be of type string. Both can exist too, in the case "new-location" would have preference. Should be handled - When changing the location of playbin2, only reset it to READY, not NULL. That should be done at other places too. Going back to NULL and then back PLAYING takes a lot of time. (In reply to comment #4) > (From update of attachment 46547 [details]) > Okay this origin check stuff looks sane to me, but i'll need to defer to a > gtk/gstreamer type person for review proper sorry :( Oliver I am not sure I did the right origin check: - if I do GtkLauncher <uri-of-the-mov>, it works fine - but if I use the video-player.html the origin check fails because the SecurityOrigin of the Document is for the file:// uri and the mov uri is an http uri. In the second case it should work too, no? Created attachment 46923 [details]
media redirections support
Comment on attachment 46923 [details] media redirections support Ah right, i see what you're doing, you're doing an origin check of the document versus the media. That's not what we want to do. What we want to do is make any redirect in the media that goes to a different origin from the current origin be forbidden Eg. if i have http://example.com/foo.mov and that media file contains a redirect to http://example.com/foo2.mov that's okay, if i instead it redirects to http://evil.com/foo.mov then the media should be blocked. This has nothing to do with the containing document. Created attachment 46987 [details]
media redirections support
Comment on attachment 46987 [details]
media redirections support
This looks good, but you should see if you can make a testcase tp ensure an unsafe redirect is blocked, and a safe one is not. r-'ing simply due to the absence of testcases
Comment on attachment 46987 [details]
media redirections support
r=me, as eric carlson did not like the idea of testing for the cross origin blocking behaviour.
Landed as r53617. Thanks! (In reply to comment #8) > (From update of attachment 46923 [details]) > Ah right, i see what you're doing, you're doing an origin check of the document > versus the media. That's not what we want to do. What we want to do is make > any redirect in the media that goes to a different origin from the current > origin be forbidden > > Eg. if i have > > http://example.com/foo.mov and that media file contains a redirect to > http://example.com/foo2.mov that's okay, if i instead it redirects to > http://evil.com/foo.mov then the media should be blocked. This has nothing to > do with the containing document. Hi Oliver, Sorry to come again on this origin check stuff but I found one example where the redirect is done to a totally different server. http://stream.qtv.apple.com/events/jan/1001q3f8hhr/1001908r5ft6dswz_1_350_ref.mov redirects to: rtsp://a2047.v1412b.c1412.g.vq.akamaistream.net/5/2047/1412/1_h264_350/1a1a1ae555c531960166df4dbc3095c327960d7be756b71b49aa1576e344addb3ead1a497aaedf11/1001908r5ft6dswz_1_350.mov So I am not sure anymore we should do that origin check, what do you think? |