New Firefox security technology blocks Web attacks, Mozilla claims • Hacker News Board

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#11

Post by tptacek » Mon, Oct 05, 2009, 9:29 PM UTC

jfager wrote: post #9

tptacek wrote: post #8

Earlier quoted context omitted.

The libraries people use to "escape all inputs, etc" are providing effectively the same functionality as CSP is, but that's not my real concern. My real concern is, despite the fact that developers have the ability to set policies about what regions on the page can contain dynamic content, "policy" is generally too brittle to describe what people need to put on pages in real-world apps.

The libraries people use to "escape all inputs, etc" are providing effectively the same functionality as CSP is Maybe, but not everyone's using those libraries, and those libraries may themselves have bugs or may be used incorrectly. Defense-in-depth, and all that. "policy" is generally too brittle to describe what people need to put on pages in real-world apps Just reading through the spec I linked to, I don't see w…

So, getting back to what I don't get about CSP, I don't see how anyone's more likely to use a new policy specification language better than they are going to use a toolkit designed for their own web framework.

Brittleness: CSP disables tags and all the script element attributes. Almost every major website in the world uses these in some form today. Both CSP and "anti-XSS" features do server-side policy about what parts of a page can have scripts, but the "anti-XSS" features are far more flexible.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#12

Post by jerf » Mon, Oct 05, 2009, 9:43 PM UTC

tptacek wrote: post #8

jfager wrote: post #7

Earlier quoted context omitted.

I don't think I understand what you're objecting to. The way I read it, CSP is lock-down by default (if the header is sent across to opt into it), with the application developer being responsible for providing a whitelist of where code and data can be loaded from. How can you do something similar today without still taking care to escape all inputs, etc.? http://people.mozilla.org/~bsterne/content-security-policy/d..…

The libraries people use to "escape all inputs, etc" are providing effectively the same functionality as CSP is, but that's not my real concern. My real concern is, despite the fact that developers have the ability to set policies about what regions on the page can contain dynamic content, "policy" is generally too brittle to describe what people need to put on pages in real-world apps.

I don't see anything in the spec about setting "regions" of dynamic content: https://wiki.mozilla.org/Security/CSP/Spec

I understand how you could think that was what was involved, as I got the same impression from the article and also thought that was dumb. However, that's not what is going on. You shut down broad classes of functionality entirely, and are required to provide all legit Javascript through tags, which furthermore must come from your whitelisted sources.

(Actually, there are some other modes too; consult the spec for details. However, I expect this is the one people will be talking about.)

The article isn't exactly wrong, but it doesn't accurately convey what is going on, either. Basically, if you can discipline yourself well enough to only use included files (which isn't a terrible style anyhow), then this allows you to ensure that you won't execute injected content.

Is this something that you should be correctly escaping? Yes, absolutely. I am a huge advocate of that in my workplace. But I would certainly take advantage of this extra layer of protection, too, rather than rely on everybody in my company getting it all absolutely right, all the time. The problem with something like escaping is that you make one little error and you lose everything. This goes a long way towards mitigating that.

I haven't done a lot of thinking about this, but it looks good; in general, voluntarily discarding privileges you don't intend to use is a good security practice.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#13

Post by tptacek » Mon, Oct 05, 2009, 9:58 PM UTC

jerf wrote: post #12

tptacek wrote: post #8

Earlier quoted context omitted.

The libraries people use to "escape all inputs, etc" are providing effectively the same functionality as CSP is, but that's not my real concern. My real concern is, despite the fact that developers have the ability to set policies about what regions on the page can contain dynamic content, "policy" is generally too brittle to describe what people need to put on pages in real-world apps.

I don't see anything in the spec about setting "regions" of dynamic content: https://wiki.mozilla.org/Security/CSP/Spec I understand how you could think that was what was involved, as I got the same impression from the article and also thought that was dumb. However, that's not what is going on. You shut down broad classes of functionality entirely, and are required to provide all legit Javascript through tags, which…

It's my fault for being imprecise, but I'm saying, developers can already designate regions of their output as "XSS-safe" or "script-free", without a browser extension.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#14

Post by tptacek » Mon, Oct 05, 2009, 10:00 PM UTC

ajju wrote: post #10

Speaking of Mozilla security what is ex-Mozilla security chief Window Snyder upto? IIRC she used to work for Matasano previously but if she has started a new startup I'd like to keep an eye on that!

She'll be out here in a week for our crypto-for-penetration-testers class, so I'm happy to ask her.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#15

Post by jerf » Mon, Oct 05, 2009, 10:03 PM UTC

tptacek wrote: post #13

jerf wrote: post #12

Earlier quoted context omitted.

I don't see anything in the spec about setting "regions" of dynamic content: https://wiki.mozilla.org/Security/CSP/Spec I understand how you could think that was what was involved, as I got the same impression from the article and also thought that was dumb. However, that's not what is going on. You shut down broad classes of functionality entirely, and are required to provide all legit Javascript through tags, which…

It's my fault for being imprecise, but I'm saying, developers can already designate regions of their output as "XSS-safe" or "script-free", without a browser extension.

Actually, I tend to agree with your point in the other comment you made in this thread, asking who will actually use it. As one of the few who care in my company, I am both the only one who might set this up, and one of the few who are careful with my encoding in the first place. It does seem an awfully narrow target of people who can't/won't encode correctly, but will do this thing which will also be hard.

Still, I might use it, contingent on broader support and some burn-in time to ensure that it doesn't somehow create some sort of huge hole itself.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#16

Post by jfager » Mon, Oct 05, 2009, 10:29 PM UTC

tptacek wrote: post #11

jfager wrote: post #9

Earlier quoted context omitted.

The libraries people use to "escape all inputs, etc" are providing effectively the same functionality as CSP is Maybe, but not everyone's using those libraries, and those libraries may themselves have bugs or may be used incorrectly. Defense-in-depth, and all that. "policy" is generally too brittle to describe what people need to put on pages in real-world apps Just reading through the spec I linked to, I don't see w…

So, getting back to what I don't get about CSP, I don't see how anyone's more likely to use a new policy specification language better than they are going to use a toolkit designed for their own web framework. Brittleness: CSP disables tags and all the script element attributes. Almost every major website in the world uses these in some form today. Both CSP and "anti-XSS" features do server-side policy about what par…

I don't see how anyone's more likely to use a new policy specification language better than they are going to use a toolkit designed for their own web framework.

This can be an http header, so an admin or senior can configure the whitelist once at the server layer and everyone in the org reaps the benefit, even if your development toolkit has problems of its own.

CSP disables tags and all the script element attributes.

I don't do much front-end work, so correct me if I'm way off, but I was under the impression that the only reason to use script elements today was to either load your own scripts or to hack around the same-origin policy to load 3rd party scripts. That use case still works under CSP, as long as the site you're loading from is in the whitelist.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#17

Post by tptacek » Mon, Oct 05, 2009, 11:33 PM UTC

jfager wrote: post #16

tptacek wrote: post #11

Earlier quoted context omitted.

So, getting back to what I don't get about CSP, I don't see how anyone's more likely to use a new policy specification language better than they are going to use a toolkit designed for their own web framework. Brittleness: CSP disables tags and all the script element attributes. Almost every major website in the world uses these in some form today. Both CSP and "anti-XSS" features do server-side policy about what par…

I don't see how anyone's more likely to use a new policy specification language better than they are going to use a toolkit designed for their own web framework. This can be an http header, so an admin or senior can configure the whitelist once at the server layer and everyone in the org reaps the benefit, even if your development toolkit has problems of its own. CSP disables tags and all the script element attribute…

That's a really naive view of how app development and deployment works, so I'll sum my response to it up with, "the admin who adds the header that breaks the Javascript in a major application is going to be fired within a single digit number of Unix timeslices of the change going live."

The problem with this stuff is that it requires virtually top-to-bottom surgery on real world apps. It is another naive view of applications that says that the dangerous inputs all come from form arguments.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#18

Post by jfager » Tue, Oct 06, 2009, 12:13 AM UTC

tptacek wrote: post #17

jfager wrote: post #16

Earlier quoted context omitted.

I don't see how anyone's more likely to use a new policy specification language better than they are going to use a toolkit designed for their own web framework. This can be an http header, so an admin or senior can configure the whitelist once at the server layer and everyone in the org reaps the benefit, even if your development toolkit has problems of its own. CSP disables tags and all the script element attribute…

That's a really naive view of how app development and deployment works, so I'll sum my response to it up with, "the admin who adds the header that breaks the Javascript in a major application is going to be fired within a single digit number of Unix timeslices of the change going live." The problem with this stuff is that it requires virtually top-to-bottom surgery on real world apps. It is another naive view of appl…

Wait, what? Of course an admin wouldn't just turn it on out of the blue one day, and of course that would be really, really stupid, but admins on the edge are responsible for stuff like this all the time. Turning on compression, setting up firewall rules, configuring caches.

Companies serve old applications, companies serve applications built on different platforms, companies get caught without the resources to rewrite insecure applications that pay the bills. You really think this is something that an ops team wouldn't love to have in its toolbox, to use as needed and where appropriate?

The problem with this stuff is that it requires virtually top-to-bottom surgery on real world apps.

If you can't use it in your app or environment without a huge rewrite, then don't. If you can, then it's gravy.

It is another naive view of applications that says that the dangerous inputs all come from form arguments.

I never said or implied they did, and that's not the only threat this proposal addresses.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#19

Post by tptacek » Tue, Oct 06, 2009, 12:51 AM UTC

jfager wrote: post #18

tptacek wrote: post #17

Earlier quoted context omitted.

That's a really naive view of how app development and deployment works, so I'll sum my response to it up with, "the admin who adds the header that breaks the Javascript in a major application is going to be fired within a single digit number of Unix timeslices of the change going live." The problem with this stuff is that it requires virtually top-to-bottom surgery on real world apps. It is another naive view of appl…

Wait, what? Of course an admin wouldn't just turn it on out of the blue one day, and of course that would be really, really stupid, but admins on the edge are responsible for stuff like this all the time. Turning on compression, setting up firewall rules, configuring caches. Companies serve old applications, companies serve applications built on different platforms, companies get caught without the resources to rewri…

The difference between CSP and compression, firewall rules, and caching are that CSP alters the way the application works, and the others don't. I've seen drama just in getting modsecurity deployed, and modsecurity is much less intrusive than CSP.

Re: New Firefox security technology blocks Web attacks, Mozilla claims

#20

Post by jfager » Tue, Oct 06, 2009, 1:31 AM UTC

tptacek wrote: post #19

jfager wrote: post #18

Earlier quoted context omitted.

Wait, what? Of course an admin wouldn't just turn it on out of the blue one day, and of course that would be really, really stupid, but admins on the edge are responsible for stuff like this all the time. Turning on compression, setting up firewall rules, configuring caches. Companies serve old applications, companies serve applications built on different platforms, companies get caught without the resources to rewri…

The difference between CSP and compression, firewall rules, and caching are that CSP alters the way the application works, and the others don't. I've seen drama just in getting modsecurity deployed, and modsecurity is much less intrusive than CSP.

We're talking about bits an admin can flip to get fired, aren't we? To that question, I don't really see what you get from the distinction...