Closed Bug 1550414 Opened 6 years ago Closed 5 years ago

CSP bypass: child frame setting parent location to a javascript: url

Categories

(Core :: DOM: Security, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: whitehat002, Assigned: ckerschb)

References

Details

(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?][domsecurity-active])

Attachments

(2 files)

Attached image csp_bypass.png

environment:
windows 10
Firefox 66.0.5 x64

Xss is triggered when the victim opens csp.html.

poc:
csp.html

<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
<script>alert(location.href)</script>
<iframe src=./xs.html>

xs.html

<script>
parent.window.location ="javascript:alert(location.href)";
</script>
Flags: sec-bounty?
Group: firefox-core-security → dom-core-security
Component: Security → DOM: Security
Product: Firefox → Core
See Also: → 1550499
Type: task → defect

Is this bug a duplicate?I am able to get the xss data.

Not sure if this one is a bug yet or not. Need to set up a testcase and try a few things and haven't gotten to it yet.

The top-frame CSP only applies to the top frame. The frame xs.html has no CSP and can run any script it wants. In this particular case it's same-origin with its parent so if it wanted to find out the parent's location it could just do alert(parent.window.location) -- not very interesting.

The question is about that javascript url. If the top frame tried to use a javascript: url it would be blocked as in-line script. Is this testcase like that, or is it more like an external entity navigating the window in which case the CSP wouldn't apply.

Flags: needinfo?(dveditz)
Flags: needinfo?(dveditz)
Summary: CSP bypass vulnerability → CSP bypass: child frame setting parent location to a javascript: url

This only "works" because the child frame is same-origin, which means this is not a security bug (it can get all the information directly once it has a reference). The "wrong" CSP is being checked because it's the child's principal behind the script setting the new location, and in the future (bug 965637) we won't have that and will presumably check the correct document's CSP.

It would be a horrible Universal-XSS if cross-origin javascript: location setting were allowed, with or without CSP involved.

Blocks: 965637
Group: dom-core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: sec-bounty? → sec-bounty-
Priority: -- → P3
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][domsecurity-backlog3]

Although this is the case, edge and chrome block this situation. CSP does not allow sub page to execute information about the parent page.

(In reply to hackyzh from comment #4)

Although this is the case, edge and chrome block this situation. CSP does not allow sub page to execute information about the parent page.

I just wrote an automated test using the STRs from comment 0. It seems our internal re-architecture of where the CSP lives (see Bug 965637) will also fix that problem and will make Firefox compliant with the behavior of other platforms.

Assignee: nobody → ckerschb
Status: NEW → ASSIGNED
Priority: P3 → P2
Whiteboard: [reporter-external] [client-bounty-form] [verif?][domsecurity-backlog3] → [reporter-external] [client-bounty-form] [verif?][domsecurity-active]

Bug 1555043 might well affect the behavior here.

Depends on: 1555043
Pushed by mozilla@christophkerschbaumer.com: https://hg.mozilla.org/integration/autoland/rev/a50c36fad95a Add CSP test for setting parent location to javascript:. r=jkt
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: