Open
Bug 1473321
Opened 7 years ago
Updated 8 months ago
sandboxed cross-origin iframe with allow-same-origin flag allows getUserMedia without proper allow flag
Categories
(Core :: WebRTC: Audio/Video, defect, P3)
Tracking
()
NEW
| Tracking | Status | |
|---|---|---|
| firefox62 | --- | affected |
People
(Reporter: tobias.boehmer, Unassigned)
References
Details
Attachments
(1 file)
|
1.95 KB,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180605171542
Steps to reproduce:
- have an <iframe sandbox="allow-scripts allow-same-origin"> with a cross-origin origin inside a website (see attached demo.html)
- request the camera from within that iframe via `navigator.mediaDevices.getUserMedia()`
- the permission-prompt will pop up
- grant permission
Actual results:
The videosource was succesfully captured an (in my demo) streamed to the <video> element.
Expected results:
For me there are two possible locations for the issue:
- [option 1] the permission prompt should not show up and an Error should be thrown (like: `MediaStreamError { name: "NotReadableError", message: "Failed to allocate videosource", constraint: "", stack: "" }` as it is thrown if the `allow-same-origin` flag is omitted) and the Promise rejects
- [option 2] the permission prompt will show up and an Error (like in option 1) is thrown and the Promise rejects
Note: I find it odd, that in the first case in the demo (see attached demo.html) when the `allow-same-origin` flag is missing the permission prompt will show up and draw the users attention just to not result in a successful videosource anyway but throwing an Error and reject the Promise anyway.
| Reporter | ||
Comment 1•7 years ago
|
||
Updated•7 years ago
|
Component: Security → WebRTC
Updated•7 years ago
|
status-firefox62:
--- → affected
Comment 2•7 years ago
|
||
Can you explain please why iframe-with-getUserMedia.html in <iframe sandbox="allow-scripts allow-same-origin"> should not be able to stream the videosource to its own video element?
Does the prompt show the origin of iframe-with-getUserMedia?
Is there another allow-* flag that should be involved?
| Reporter | ||
Comment 3•7 years ago
|
||
(In reply to Karl Tomlinson (:karlt) from comment #2)
> Can you explain please why iframe-with-getUserMedia.html in <iframe
> sandbox="allow-scripts allow-same-origin"> should not be able to stream the
> videosource to its own video element?
>
> Does the prompt show the origin of iframe-with-getUserMedia?
>
> Is there another allow-* flag that should be involved?
Yes, the prompt shows the (correct) origin, in both cases.
But please do not confuse the origins. For the Bug to show up it is important, that the main "demo.html" is served from another origin than both iframes! So both iframes are equally cross-origin (in my case they share a origin). The bug lies in the different behavior of the response to the (in my case: granted) permission to get the user media.
Case 1: WITHOUT the "allow-same-origin" flag it fails with `MediaStreamError { name: "NotReadableError", message: "Failed to allocate videosource", constraint: "", stack: "" }` (copied from my console).
Case 2: WITH the "allow-same-origin" flag it succeeds with a video steam, even though it's still a cross-origin (the origin still differs from the main document). I Think it still should fail, since there is no flag allowing access to the camera and it's still a sandboxed cross-origin iframe.
Flags (allow-*) that may be involved may be: <iframe ... allow="camera *; microphone *;"> (maybe I got the syntax wrong? and I could not find the spec anymore that describes this attribute anyway)
But by demo works without them. Just split the code into two files, serve them from different origins and change the src-url of the iframes accordingly.
But I have to admit, that I may have confused you by pointing out that I think every behavior you see there has its problems. One question that comes up for me is:
Why does a permission-prompt shows up in "Case 1", even though it fails with a MediaStreamError afterwards when I grant permission to my camera? (maybe another issue?)
Related issues may also be (bug 1389198).
Comment 4•7 years ago
|
||
(In reply to tobias.boehmer from comment #3)
> (In reply to Karl Tomlinson (:karlt) from comment #2)
> > Can you explain please why iframe-with-getUserMedia.html in <iframe
> > sandbox="allow-scripts allow-same-origin"> should not be able to stream the
> > videosource to its own video element?
> > Is there another allow-* flag that should be involved?
> Case 2: WITH the "allow-same-origin" flag it succeeds with a video steam,
> even though it's still a cross-origin (the origin still differs from the
> main document). I Think it still should fail, since there is no flag
> allowing access to the camera and it's still a sandboxed cross-origin iframe.
>
> Flags (allow-*) that may be involved may be: <iframe ... allow="camera *;
> microphone *;"> (maybe I got the syntax wrong? and I could not find the spec
> anymore that describes this attribute anyway)
> Related issues may also be (bug 1389198).
Thanks.
I think bug 1389198 will cover switching to Chrome's behavior for this case,
(which is what you expect IIUC) even though that bug's title does not make
deprecation of support clear, but I'll leave this open for now and those
working on this can decide.
> Why does a permission-prompt shows up in "Case 1", even though it fails with
> a MediaStreamError afterwards when I grant permission to my camera? (maybe
> another issue?)
That sounds like a (different) bug to me.
Component: WebRTC → WebRTC: Audio/Video
Priority: -- → P2
Comment 5•6 years ago
|
||
Is there an ETA for this bug to get fix?
Comment 6•3 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•3 years ago
|
Severity: normal → S3
Updated•8 months ago
|
Priority: P2 → P3
You need to log in
before you can comment on or make changes to this bug.
Description
•