
New Firefox security technology blocks Web attacks, Mozilla claims - ksvs
http://www.computerworld.com/s/article/9138918/New_Firefox_security_technology_blocks_Web_attacks_Mozilla_claims
======
ax0n
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.

~~~
tptacek
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?

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

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

~~~
jfager
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...](http://people.mozilla.org/~bsterne/content-security-
policy/details.html)

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

~~~
jerf
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 <script> 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.

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

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

------
ax0n
Also, it seems Computerworld believes it's similar to NoScript (which I use)
whereas it really seems more like RequestPolicy (which I also use, but
wouldn't wish upon anyone that's not equal parts sophisticated and paranoid)

------
ajju
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!

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

