Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSP and Referrer-Policy meta tag not recognized #105

Closed
realFlowControl opened this issue Aug 31, 2016 · 18 comments
Closed

CSP and Referrer-Policy meta tag not recognized #105

realFlowControl opened this issue Aug 31, 2016 · 18 comments

Comments

@realFlowControl
Copy link

Having the CSP-Header in a HTML-Meta tag seems not to be recognized, although it is stated here as an implemenation example: https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy

See here: https://observatory.mozilla.org/analyze.html?host=dotbox.org

@april
Copy link
Contributor

april commented Aug 31, 2016

Yep, I've even got a comment about it in the code. :)

https://github.com/mozilla/http-observatory/blob/master/httpobs/scanner/analyzer/headers.py#L34

Thanks for bringing this up!

@travisspencer
Copy link

+1 We use CSP in meta only (except for frames which have to be in headers). Would be nice to have this reported more completely.

@april
Copy link
Contributor

april commented Nov 14, 2016

I'm really hoping to get to this sometime this quarter. If not, early next quarter. It's definitely not being ignored, just something that I haven't had time to get to you. :)

@april april changed the title CSP as HTML-Meta-Tag not recognized CSP and Referrer-Policy meta tag not recognized Dec 8, 2016
toomuchio added a commit to toomuchio/http-observatory that referenced this issue Jan 25, 2017
This probably isn't ideal, couldn't really defend importing a heavy package like bs4 to myself when a simple regex can do the job. At the very least this pull request might encourage somebody to take another look at this or perhaps my simple approach is good enough.

mozilla#105
@kspearrin
Copy link

Any update here?

@april
Copy link
Contributor

april commented Aug 30, 2017

@travisspencer, do you have a test site I can use to verify my changes? Thanks!

@kspearrin
Copy link

@april See https://vault.bitwarden.com to test

@april
Copy link
Contributor

april commented Aug 30, 2017

Awesome! It's passing all my tests and your site went from a D+ to a B (CSP is now "unsafe in style-src only"). I've still got to revamp some of the other tests that use headers, such as Referrer-Policy.

@april
Copy link
Contributor

april commented Sep 6, 2017

Fixed in #264 and now live. :)

@april april closed this as completed Sep 6, 2017
@travisspencer
Copy link

Sorry, @april , for not replying earlier. I just tested https://nordicapis.curity.io/oauth/v2/authorize and the results are wrong IMO. It gives a -20 for using unsafe-inline like this:

<meta http-equiv="Content-Security-Policy" content="img-src 'self'; style-src 'self' 'unsafe-inline' 'nonce-gAeQO8jI4VJCsrsXkcUVRCzQjiihKteQ';">

There is no way to support nonce in a backward-compatible way without unsafe-inline. With the nonce, user agents that support nonce will ignore the unsafe-line. See this question on SO for more details. Also, see Mozilla's other site for reference.

@april
Copy link
Contributor

april commented Sep 6, 2017

Right, but you don't have a nonce inside script-src, you have a nonce inside style-src.

As you can see here:
https://www.twoevils.org/html/test/csp-nonce-unsafe-1.html

Your policy does nothing to protect against unsafe-inline script. In this case, the Observatory is correct – your CSP is actually unsafe.

@travisspencer
Copy link

are we looking at the same page or am I just daft? (I may well be) At that URL, I see this markup:

<head>

<meta http-equiv="Content-Security-Policy" content="object-src 'none'; media-src 'none';">
<meta http-equiv="Content-Security-Policy" content="connect-src 'self'; font-src 'self'; child-src 'self';">
<meta http-equiv="Content-Security-Policy" content="img-src 'self'; style-src 'self' 'unsafe-inline' 'nonce-gAeQO8jI4VJCsrsXkcUVRCzQjiihKteQ';">
<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline' 'nonce-gAeQO8jI4VJCsrsXkcUVRCzQjiihKteQ';">

<style id="antiClickjack" nonce="gAeQO8jI4VJCsrsXkcUVRCzQjiihKteQ">/*...*/</style>

<script type="text/javascript" nonce="gAeQO8jI4VJCsrsXkcUVRCzQjiihKteQ">/*...*/</script>
<script type="text/javascript" nonce="gAeQO8jI4VJCsrsXkcUVRCzQjiihKteQ">/*...*/</script>

</head>

The 3rd meta tag allows styles (style-src, the one I included in the last comment) to run with unsafe-inline if the user agent doesn't support nonce, and the 4th one does the same for scripts (script-src).

So, this page is safe (as long as the user agent support's nonce). What is the problem here that I'm missing?

@floatingatoll
Copy link
Contributor

floatingatoll commented Sep 6, 2017 via email

@april
Copy link
Contributor

april commented Sep 6, 2017

I didn't look at your page, I only looked at what you posted in the thread. I'll take a look at it, but I suspect what's happening is that it's only seeing either the first or last entry.

@travisspencer
Copy link

travisspencer commented Sep 6, 2017 via email

@floatingatoll
Copy link
Contributor

floatingatoll commented Sep 6, 2017 via email

@april
Copy link
Contributor

april commented Sep 6, 2017

Okay, so there is a bug where it's not combining them together. I'll work on fixing that. That said, the Observatory has historically only looked at the page's contents when it returns a 200 code, not 400 or 404.

The reason for this is that most sites (not yours, in this case) have really bad error pages, and I didn't want to tell them that they were safe due to not having scripts (such as with SRI) on their error pages, when their normal pages did have issues. I can possibly fix this, but it will probably take me a while.

@april
Copy link
Contributor

april commented Sep 6, 2017

Could I ask you to open another bug for this? In the vast majority of situations, this code as it is should work for websites. Most sites only use a singular meta http-equiv and don't have error pages for /. :)

@travisspencer
Copy link

Created two new tickets for ya, @april . If there's anything I can do to help besides testing and verification, please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants