Live data from Hacker News

New Firefox security technology blocks Web attacks, Mozilla claims

computerworld.com

1–10 of 20 posts

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

#2
Up next: New attack bypasses Firefox security technology, security researcher claims.

I do infosec for a living. I can say with 100% certainty that the good guys are in a constant state of playing catch-up with the bad guys. The only thing we can hope for is to minimize the amount of time that serious vulnerabilities remain exposed, in hopes that it's fixed before someone creates yet another point-and-crack tool for the skiddies.

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

#3
I don't really get CSP. Without changing anything in the browser, application developers --- the only people who can really use CSP --- can already create policies that say where dynamic code should or shouldn't be allowed.

The problem is that modern web apps are riddled with places that need enough dynamicism that blunt filtering won't work.

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

#4
post #2

Up next: New attack bypasses Firefox security technology, security researcher claims. I do infosec for a living. I can say with 100% certainty that the good guys are in a constant state of playing catch-up with the bad guys. The only thing we can hope for is to minimize the amount of time that serious vulnerabilities remain exposed, in hopes that it's fixed before someone creates yet another point-and-crack tool for…

Without saying why CSP is particularly susceptable to cat-and-mouse attacks, this comment doesn't have a lot of content. Do you have more thoughts to share about it?

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

#6
post #4
post #2

Up next: New attack bypasses Firefox security technology, security researcher claims. I do infosec for a living. I can say with 100% certainty that the good guys are in a constant state of playing catch-up with the bad guys. The only thing we can hope for is to minimize the amount of time that serious vulnerabilities remain exposed, in hopes that it's fixed before someone creates yet another point-and-crack tool for…

Without saying why CSP is particularly susceptable to cat-and-mouse attacks, this comment doesn't have a lot of content. Do you have more thoughts to share about it?

Some big problems: It requires people to use firefox or for other vendors to adopt CSP, and it only works for sites that integrate it. Until it comes under attack, it's hard to say whether or not it'll fall victim to the cat-and-mouse thing or simply fail to gain traction. I haven't seen CSP in action, so my comment was tongue-in-cheek.

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

#7
post #3

I don't really get CSP. Without changing anything in the browser, application developers --- the only people who can really use CSP --- can already create policies that say where dynamic code should or shouldn't be allowed. The problem is that modern web apps are riddled with places that need enough dynamicism that blunt filtering won't work.

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...

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

#8
post #7
post #3

I don't really get CSP. Without changing anything in the browser, application developers --- the only people who can really use CSP --- can already create policies that say where dynamic code should or shouldn't be allowed. The problem is that modern web apps are riddled with places that need enough dynamicism that blunt filtering won't work.

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.

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

#9
post #8
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.

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 what would be particularly brittle about it. Do you have an example of a real-world use case that this would hamper?

Post reply on HN