Content Security Policy

#1

Post by xPaw » Fri, Apr 19, 2013, 2:36 PM UTC

Content Security Policy
github.com

Re: Content Security Policy

#2

Post by mh- » Fri, Apr 19, 2013, 2:44 PM UTC

This entire post is like a "why CSP is broken in the real world", yet they're going ahead with deploying it?

Re: Content Security Policy

#3

Post by pfraze » Fri, Apr 19, 2013, 2:45 PM UTC

You can also specify a CSP using a document's meta tags:

I'm not sure if that introduces any additional attack vectors (other than somebody modifying the document in an unencrypted connection) but it's useful for when hosting statically.

EDIT: updated to mimic example in post

Re: Content Security Policy

#4

Post by thyrsus » Fri, Apr 19, 2013, 3:12 PM UTC

mh- wrote: post #2

This entire post is like a "why CSP is broken in the real world", yet they're going ahead with deploying it?

"You must be the change you want to see in the world." - Gandhi

Re: Content Security Policy

#5

Post by ushi » Fri, Apr 19, 2013, 3:49 PM UTC

pfraze wrote: post #3

You can also specify a CSP using a document's meta tags: I'm not sure if that introduces any additional attack vectors (other than somebody modifying the document in an unencrypted connection) but it's useful for when hosting statically. EDIT: updated to mimic example in post

> it's useful for when hosting statically.

You can configure your webserver to add those headers, when hosting statically. There is no need to include it in all your pages.

nginx: add_header Content-Security-Policy "...";

Re: Content Security Policy

#6

Post by joshpeek » Fri, Apr 19, 2013, 3:53 PM UTC

ushi wrote: post #5

pfraze wrote: post #3

You can also specify a CSP using a document's meta tags: I'm not sure if that introduces any additional attack vectors (other than somebody modifying the document in an unencrypted connection) but it's useful for when hosting statically. EDIT: updated to mimic example in post

> it's useful for when hosting statically. You can configure your webserver to add those headers, when hosting statically. There is no need to include it in all your pages. nginx: add_header Content-Security-Policy "...";

If your site is a simple static blog or whatever, there probably is no XSS vector. So you probably don't need CSP.

Re: Content Security Policy

#7

Post by abarth » Fri, Apr 19, 2013, 4:51 PM UTC

mh- wrote: post #2

This entire post is like a "why CSP is broken in the real world", yet they're going ahead with deploying it?

Their feedback is very useful to us as we iterate on the specification and implementation of CSP. (Disclosure: I'm an editor of the CSP specification.)

Re: Content Security Policy

#8

Post by dmethvin » Fri, Apr 19, 2013, 5:18 PM UTC

abarth wrote: post #7

mh- wrote: post #2

This entire post is like a "why CSP is broken in the real world", yet they're going ahead with deploying it?

Their feedback is very useful to us as we iterate on the specification and implementation of CSP. (Disclosure: I'm an editor of the CSP specification.)

Thanks for your work! I'm a fan of CSP's goals.

Re: Content Security Policy

#9

Post by byroot » Fri, Apr 19, 2013, 5:21 PM UTC

This change broke our chrome extension a few weeks ago. We were able to workaround it using a trick inspired by this blog post: http://brianmayer.com/2012/12/defeating-chromes-content-secu...

Hope it help someone.

Re: Content Security Policy

#10

Post by dmethvin » Fri, Apr 19, 2013, 5:23 PM UTC

Its great to see a large site like GitHub start work on deploying CSP. I don't know how many times I've had to argue with people about bad practices like inline event handlers. With CSP there's a way for a site to prevent them from being used.