Page 2 of 3

Re: Content Security Policy

Posted: Mon Jan 04, 2016 11:08 pm
by MikeGale
This looks sensible, given that level 1 is used with both the X-... header and the plain one, to bring in as many browsers as possible. (see http://caniuse.com/#feat=contentsecuritypolicy)

I haven't figured out why they don't have a reporting URI in the meta tag form. Anybody know?

I just checked Facebook. I think they used to have it but don't now. Maybe it's that inline code and the hostile approach of the specification to it (defining a value of 'unsafe-inline' is not going to win over some developers!). Has anybody done or seen a cross site analysis of how many are using it?

Re: Content Security Policy

Posted: Tue Jan 05, 2016 7:50 am
by Albert Wiersch
MikeGale wrote:I haven't figured out why they don't have a reporting URI in the meta tag form. Anybody know?
Good question. I don't recall coming across any answer when I was researching CSP. The spec just says it's not supported and I recall no reason why.
MikeGale wrote:I just checked Facebook. I think they used to have it but don't now. Maybe it's that inline code and the hostile approach of the specification to it (defining a value of 'unsafe-inline' is not going to win over some developers!).
I wouldn't be surprised if most people and businesses are finding it more problematic and limiting than actually useful and beneficial.
MikeGale wrote:Has anybody done or seen a cross site analysis of how many are using it?
I'd like to see this to. I did a quick search and couldn't find anything.

Here is an interesting link about breaking things even if you use correct CSP (due to bad browser implementation):
https://www.troyhunt.com/how-to-break-y ... h-content/

Also, here is a good introduction for CSP if anyone wants to learn more:
https://web.dev/articles/csp

I found this Mozilla reference useful too:
https://developer.mozilla.org/en-US/doc ... curity/CSP

Especially this page about the directives:
https://developer.mozilla.org/en-US/doc ... directives

Re: Content Security Policy

Posted: Tue Jan 05, 2016 5:21 pm
by MikeGale
Thanks for that.

I saw a link that basically said, this will explain why meta has no report-uri, when I looked, no explanation. Presumably removed.

Thanks for the Troy link. (I'd also identified the others and like them too.) (The site https://report-uri.io/ also appears to give a useful service.)

This link http://embedthis.com/blog/posts/content-security-policy/ is interesting. It reveals that all the sneaky things that the surveillance/advertising people are doing, might doom this technology, if you use their recommended off site code and resources. (A thing I avoid wherever I can. It's just unwise.) The corollary is that this will really work for you if you do your own design and hosting, but might need CDN or something like that.

Ironic that one hand of Alphabet / Google is driving this approach, while the other hand is making it unworkable!

I see two good scenarios to use this:
  1. You're in control of all content and resources and you have a policy to stay that way.
  2. You want additional exception logging, and use this with reporting mode only, indefinitely.

Re: Content Security Policy

Posted: Tue Jan 05, 2016 5:51 pm
by Albert Wiersch
MikeGale wrote:This link http://embedthis.com/blog/posts/content-security-policy/ is interesting.
That was a good read and gives a great explanation of why CSP is not used as much as one might think, so thanks for the link. I suggest everyone interested in CSP put that on their required reading list. :D

At least CSP is simple and effective for self-contained systems. There's little reason not to use it there.

Re: Content Security Policy

Posted: Mon Jan 11, 2016 6:53 pm
by MikeGale
I'm having a deeper look at this and similar directives, to do that I've nearly completed an informal logging system. Is there anything that I'm missing? (I'm logging both HTTP headers and Markup headers):
HTTP Headers: Content-Security-Policy, X-Content-Security-Policy, Content-Security-Policy-Report-Only, X-Content-Security-Policy-Report-Only, Public-Key-Pins, Public-Key-Pins-Report-Only, AccessControl-Allow-Origin, X-XSS-Protection, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security
Markup-Headers: Content-Security-Policy, X-Content-Security-Policy (with three parameters removed/ignored should they exist)

Re: Content Security Policy

Posted: Mon Jan 11, 2016 10:08 pm
by Albert Wiersch
Hi Mike,

If you are asking me then I'd have to say that I don't know... I'm not that well versed in the security aspects of web development as CSS HTML Validator is not a security product. However, during your research, if you find something that would be a good check to add to CSS HTML Validator then please let me know. While it's not a security product, if the new check is something that's useful yet not too difficult to add then I would definitely want to look into it.

Re: Content Security Policy

Posted: Mon Jan 11, 2016 11:39 pm
by MikeGale
Hi Albert,

Thanks. The question was directed at all comers. I'd appreciate insights into this area.

(I assume that theoretically all HTTP headers can have a meta http-equiv tag, but for security headers it may be (not checked by me) that most don't. I've only looked at the RFC's for CSP and key pins for details of meta support. I haven't yet grokked this sufficiently.)

(I guess that the CSP may interact with validation a little. If it is used to "widen" default restrictions, then pages can fail if a browser doesn't support it.)

Update 2016-01-13 I imagine you're already onto the interaction areas. The things that I've noticed and might have value are:
  1. HTTP headers take precedence over http-equivs
  2. Three parameters are dropped if they occur in a CSP meta tag (report-uri, frame-ancestors, and sandbox)
  3. User Agents are required by the RFC's to drop any report only meta-tags and some of the other http headers, should they occur.
  4. Browser support for level 1 CSP is better than level 2.
  5. The X-... headers may also be needed given current browser capabilities

Re: Content Security Policy

Posted: Tue Jan 26, 2016 3:16 pm
by MikeGale
I see that Scott Helme has launched a site that rates web sites. It seems based on HTTP headers (not HTML headers) but will, no doubt, impact people here. It presents "grades" based on these headers, seemingly based on the Qualys SSL rating system.

If you're going to use this I recommend ticking the don't remember / show box, until you know what is going on. (That way you reduce the chance of trumpeting bad ratings before you have a chance to think it through.)

Caveats
  1. If a site uses a lot of third party code, like advertising and surveillance links, "good practice" may be impractical
  2. Certificate pinning requires control and foresight that may also be impractical
  3. I'm sure there's more. Worth thinking about before somebody asks you the questions.
It's at https://securityheaders.io/.

Re: Content Security Policy

Posted: Fri Jan 29, 2016 2:27 pm
by Albert Wiersch
Thanks Mike. That looks like a great site for analyzing HTTP security headers and gives me some ideas for adding some basic HTTP header security checks for a future updates of CSS HTML Validator. While not a security product, I don't mind adding some 'basic' stuff that is simple to add yet still can be very helpful.

Definitely check that "Hide results" box when getting started! :D

Re: Content Security Policy

Posted: Fri Jan 29, 2016 5:54 pm
by MikeGale
That sounds good Albert.

I think it only a matter of time before people cotton on to the deep hole that humanity is falling into and pay more attention to security.

Re: Content Security Policy

Posted: Tue Feb 16, 2016 11:17 am
by RSteinwand
I can't imagine getting any serious work done with it in place.

Re: Content Security Policy

Posted: Wed Jul 26, 2017 2:31 pm
by RSteinwand
Well, this is me, having to set a Content Security Policy header and update styles and scripts so they still work: :?

I don't have anything to check with CSE yet, but will soon find out how it works. I found out real quick that it's easy to break a site, even if it's just development, with the wrong header.

Here's a good link: https://scotthelme.co.uk/content-securi ... roduction/

Incidentally, this is a great tool to see how secure your implementation is: https://securityheaders.io/

I have two headers down and at least one more (CSP) to go.

Wish me luck. I'm going to need it. :D

Re: Content Security Policy

Posted: Fri Jul 28, 2017 4:26 pm
by Albert Wiersch
RSteinwand wrote: Wed Jul 26, 2017 2:31 pm Incidentally, this is a great tool to see how secure your implementation is: https://securityheaders.io/
Thanks. I like that site and got mine up to an "A" as of now. I have also improved some of the security messages that CSS HTML Validator generates for the next minor update.
RSteinwand wrote: Wed Jul 26, 2017 2:31 pm Wish me luck. I'm going to need it. :D
Good luck!

Re: Content Security Policy

Posted: Sat Jul 29, 2017 9:44 am
by RSteinwand
I don't know why I checked, but I noticed your site was looking pretty good and wondered if it was from my link.

Re: Content Security Policy

Posted: Fri Oct 06, 2017 1:48 pm
by RSteinwand
Albert Wiersch wrote: Tue Jan 05, 2016 7:50 am Here is an interesting link about breaking things even if you use correct CSP (due to bad browser implementation):
https://www.troyhunt.com/how-to-break-y ... h-content/
Thanks for the link. Great read!

It's been several months since implementing CSP. The first problem I noticed was a YouTube video on our home page was broken (and it was broken for about a week before I noticed it). So I found all the Google domains I needed and it turns out I only needed youtube.com. :shock: Apparently since it was a iframe, I didn't need the rest.

So just now reading the link you posted ages ago, I see I should be using frame-src & child-src for things like Youtube.

... and as for your comment about it only being needed for financial web sites, we provide financial services including storing credit card data, so that's why we get stuck with these requirements.