Open Bug 1407197 Opened 7 years ago Updated 2 years ago

Content-Security-Policy meta tag provided by iframe content working on dynamic content of the whole page

Categories

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

Product:
Core
Component:
DOM: Security
Version:
56 Branch
Type:
defect

Tracking

()

People

(Reporter: artperit, Unassigned)

References

(
URL
)

Details

(Whiteboard: [domsecurity-backlog])

Attachments

(1 file)

issue.png
63.66 KB, image/png
Details
Attached image issue.png — 
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce:

I created 2 html files.

test.html

</html>
  <head></head>
  <body>
    <form>
      <input type="button" id="btn" value="GO" />
    </form>
    <script type="text/javascript">
      document.getElementById('btn').onclick = function() {
      src = 'https://www.google.ru/logos/doodles/2017/fridtjof-nansens-156th-birthday-5694774550986752-s.png',
      img = document.createElement('img');
      img.src = src;
      document.body.appendChild(img);
    }
    </script>
    <img src="https://www.google.ru/logos/doodles/2017/fridtjof-nansens-156th-birthday-5694774550986752-s.png"/>
    <iframe src="iframe.html"></iframe>

  </body>
</html>

iframe.html

<html>
  <head>
    <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src 'self' data:; script-src 'self' *.jquery.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; font-src 'self' data:;"></meta>
  </head>
  <body style="font-family: Arial; font-size: 13px;">
    <br>
  </body>
</html>

Then i load test.html in Firefox v56 and click "GO" button


Actual results:

Page didn't change, error shows up in console :

Content Security Policy: The page’s settings blocked the loading of a resource at https://www.google.ru/logos/doodles/2017/fridtjof-nansens-156th-birthday-5694774550986752-s.png (“img-src file:// data:”)


Expected results:

Image with URL (https://www.google.ru/logos/doodles/2017/fridtjof-nansens-156th-birthday-5694774550986752-s.png) must be added to page everytime "GO" button pressed. 
Works in latest Google Chrome, Edge.
Still present in FF 58 

In summary : 
- if you set Content Security Policy inside iframe - it will propagate to parent (like in Artem example - adding new image in parent part will be blocked by iframe CSP) 
- same bug is present with iframe using srcdoc (with static or dynamic changing value of srcdoc)
- if you set Content Security Policy and want to change it (remove/replace restrictions) it will not work
- if you open new window from CSP affected page, new page will be affected too (f.e. script or meta refresh will not work on newly open page)
- even when remove iframe from DOM, CSP still is working!
- very problematic on dynamic content pages (like angular based) - iframe can be removed (controller change) but CSP once present will affect all next pages

All above working properly in Chrome.
any news on this? bug is still present in FF60.0.2
Component: Security → DOM: Security
My guess is this is an offshoot of how we handle file:// origins. When one file frames another in the same directory or a sub-directory then we consider it "same-origin" (unlike other browsers -- there's no spec for file:). Our implementation of this is accomplished by copying the "principal", which is where the CSP lives (currently; we're changing this).

This shouldn't happen on a real web site. Can you test that?

This wouldn't happen for file: if we implement bug 803143  (matching chrome's unique origin for file:)
This won't happen after we move CSP from the principal to loadinfo (don't have the bug number handy)

If this behavior is limited to local file:// cases then it's low priority.
Flags: needinfo?(artperit)
(In reply to Daniel Veditz [:dveditz] from comment #3)

Wrong.

This is not connected with file://

FULL SAMPLE:  http://blazej.com/firefox/iframe_ff_fail.html
Thank you, dev. clearing needinfo from artem because we have what we need now.

Christoph:
srcdoc frames are same-origin with the parent frame. Is it possible that we're not cloning the principal but rather just using the same one? If that's true then setting the CSP (which lives on the principal currently) would then affect the parent. and then setting a new srcdoc child would still have that same CSP so setting another CSP would add to the restrictions, not relax them.

This would be fixed when we move the CSP to the loadgroup but I don't know the timeframe on that. Should we make this depend on that and wait, or is this something we can address with the existing architecture? Of course in that world we'd have to be careful to copy a parent's CSP into the child's loadgroup.
URL: http://blazej.com/firefox/iframe_ff_f...
Flags: needinfo?(artperit)
(In reply to Daniel Veditz [:dveditz] from comment #5)
> Christoph:
> srcdoc frames are same-origin with the parent frame. Is it possible that
> we're not cloning the principal but rather just using the same one?

This is most certainly caused because we are re-using the same principal, so everything set on the CSP within an same-origin iframe (or any kind where we use the same security context within the parent and the iframe) will handle that sort of CSP extension incorrectly.

I am actively working on Bug 965637 and I hope this patch will be in review soon (like within the next two weeks).

> This would be fixed when we move the CSP to the loadgroup but I don't know
> the timeframe on that. Should we make this depend on that and wait, or is
> this something we can address with the existing architecture?

If people feel strongly we can change that bit within the current architecture. I think we just have to clone the principal instead of re-using it when we set up the iframe within nsDocument.cpp, but I guess we should rather wait for Bug 965637 to land.

Marking Bug 965637 as blocking this one.
Depends on: 965637
As discussed in the triage meeting we move this to the backlog for now since Bug 965637 is soon to be ready for review and will fix that problem here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [domsecurity-backlog]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: