W3C home > Mailing lists > Public > public-identity@w3.org > December 2011

Re: The javascript runtime, XSS, and javascript crypto...

From: Tom Ritter <tom@ritter.vg>
Date: Tue, 13 Dec 2011 09:50:27 -0500
Message-ID: <CA+cU71m3fwGu+2a+BLf9wTjD92HXm0dKqA9L2beR3S+fj7GR+g@mail.gmail.com>
To: Harry Halpin <hhalpin@w3.org>
Cc: "public-identity@w3.org" <public-identity@w3.org>
> Again, look at the CSP spec and tell us if this fulfills your use-case.

Content Security Policy is another approach to solve the problem where
a single XSS flaw can poison the entire javascript runtime and subvert
the critical code.  It has its pros and cons.

Basically, it's DEP+ASLR for the web.  Just as they didn't do anything
to fix memory corruption, CSP doesn't do anything to fix XSS - they
both just try to make exploitation harder.  If I find a XSS flaw in a
web app that makes full use of CSP, making an exploit that subverts
the crypto code will be more difficult.  I really like these things
because it pushes security forward, they're positive contributions to
the field.  But they're not enough.  If the bar is raised, people will
rise to the bar: sophisticated attacks are occurring all around us.
We need to make exploitation harder while making the explotation
'hooks' (the bugs) fewer and seperating/segmenting to contain damage.

The most stringent we could make things under CSP:
 - No unsafe-inline: I can't write in a <script> element or an event
attribute.  All javascript must come from include files
 - No unsafe-eval: I can't use eval or a few functions that would let
me execute dynamically-built code
 - object-src, style-src, media-src, frame-src, font-src, connect-src
are all locked down preventing me from doing anything weird with them
like phoning home stolen data, or getting javascript execution from a
stylesheet attribute
 - script-src is locked down preventing me from including a javascript
file from my server.

None of these prevent one of the most common flaws I see day in and
day out as a penetration tester:

Request:
	GET /resource?id=1';+function+keygen()+{+return+6;+}
Response:
	...
	var foo = 'whatever';
	var bar = '1';+function keygen() { return 6; }
	...
	
Exploits are hard, they're an entirely different beast from finding
vulnerabilities.  People have taken extremely small and difficult bugs
and produced exploits out of them - even if you're using CSP in the
most stringent[1] if I find a XSS flaw and can't exploit it, I will
assume it's because I don't know enough or haven't tried hard enough -
not that it's unexploitable.

Both my approach and CSP assume there will always be XSS flaws.  CSP
keeps the runtime intact but tries to make exploitation more
difficult.  I try to isolate the security critical code so a flaw must
be in it instead of the 95% of the code.  I like CSP, will recommend
and use it, and think it's a good addition.  But I'm not at all
convinced CSP is enough to get people to trust javascript crypto.

Scope is obviously a concern. I'm sensitive to it. I also want to try
to outline everything so we know explicitly what we are and aren't
trying to solve.

-tom

[1] CSP would only be deployed this way for an application built
ground-up.  After dealing with companies - I can hardly imagine any of
them investing the effort to make their app "no unsafe-inline"
compliant.
Received on Tuesday, 13 December 2011 15:22:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 December 2011 15:22:22 GMT