Server Side CSP
FunkyRes
I've been working on a php class that implements CSP as an output
filter on the web server before the content is ever sent to the
requesting browser. That way browsers that don't support CSP still can
have some measure of protection when a website decides to implement
CSP (and utilizes my class).
The class homepage is here:
http://www.clfsrpm.net/xss/
It's still highly experimental but it is both working as I need for
the web app I'm developing (not live) and can be played with via a
test page that has a textarea input that is (mostly) unfiltered
straight into the DOM before being run through the output filter (I
say mostly unfiltered because I use DOMDocument loadHTML() to eat the
input and it does some minor filtering of it's own)
http://www.clfsrpm.net/xss/dom_script_test.php
There are currently a few things about CSP that I am a little confused
about though -
1) if style-src does not contain the host the page is being served
from, do in-line style need to be blocked?
2) Does the host expression list limit a wildcard to the beginning of
a host expression? Obviously ending in a * (unless you intend to allow
all hosts and just have a *) is kind of worthless, but does it allow,
say, images.*.somewhere.net? Right now I assume that it does not.
3) Does CSP really block all event attributes? The wiki page doesn't
cover event attributes, but the (seems to be a little out of date)
http://people.mozilla.org/~bsterne/content-security-policy/details.html
page states that "Script called using event-handling attributes is not
executed".
The way I'm handling that in my class is to blacklist all event
attributes but allow a whitelist of event attributes that are allowed,
however, any event attributes in the whitelist can only call functions
without arguments.
4) It looks to me like frame-ancestors is something that can only be
enforced client side. Is that correct?
Sid Stamm
> I've been working on a php class that implements CSP as an output
> filter on the web server before the content is ever sent to the
> requesting browser. That way browsers that don't support CSP still can
> have some measure of protection when a website decides to implement
> CSP (and utilizes my class).
implement CSP properly, like you said there is still a small bit of
protection afforded to CSP-agnostic clients. Server-side filtering
won't be able to catch run-time DOM changes that violate the policy, so
it's probably not a good replacement, but yet another layer is nice.
> 1) if style-src does not contain the host the page is being served
> from, do in-line style need to be blocked?
I think that would be the right thing to do. We would also probably
want to block use of the style attribute in HTML tags.
> 2) Does the host expression list limit a wildcard to the beginning of
> a host expression?
Yes. *.x.y is ok, x.*.y.z is not. <host-name> is defined this way in
the draft of the spec:
https://wiki.mozilla.org/Security/CSP/Spec#Formal_Policy_Syntax
> 3) Does CSP really block all event attributes?
We're working on a more detailed description that will address details
like this. We have to allow event handlers in one way or another or
like half the web will implode. It is my thought that we should allow
event handlers in the HTML served on the main page, but they aren't
extracted from data contexts after that; basically, once the load event
fires, event handlers are frozen (except in JavaScript) and attribute
manipulation won't register new ones. Look for an update on the details
page you referenced soon.
> 4) It looks to me like frame-ancestors is something that can only be
> enforced client side. Is that correct?
Correct. You can only enforce this at the end of the line.
As I mentioned, we're working on a very detailed list of the basic
restrictions imposed on any CSP-implementing site (regardless of the
policy), and will be updating the wiki as well with more details as
discussion progresses. Thanks for the feedback!
-Sid
bst...@mozilla.com
> On 3/28/09 7:10 PM, FunkyRes wrote:> I've been working on a php class that implements CSP as an output
> > from, do in-line style need to be blocked?
>
> I think that would be the right thing to do. We would also probably
> want to block use of the style attribute in HTML tags.
I agree with this. We need to make it more clear in the spec, but I
have considered inline style as well as style attributes as being
subject to the same style-src policy as any CSS being loaded from
external stylesheets.
> > 3) Does CSP really block all event attributes?
> We're working on a more detailed description that will address details
> like this. We have to allow event handlers in one way or another or
> like half the web will implode. It is my thought that we should allow
> event handlers in the HTML served on the main page, but they aren't
> extracted from data contexts after that; basically, once the load event
> fires, event handlers are frozen (except in JavaScript) and attribute
> manipulation won't register new ones. Look for an update on the details
> page you referenced soon.
Actually, all event-handling HTML attributes will be blocked, as they
are a common vector for XSS, e.g. <body onload="evil()">. However,
sites will still be able to do event handling in the following ways:
1) setting the on<event> properties of an element, e.g. foo.onclick =
myFunc;
2) using addEventListener, e.g. foo.addEventListener("click", myFunc,
false);
Of course, both methods would have to be used from within white-listed
script files.
> As I mentioned, we're working on a very detailed list of the basic
> restrictions imposed on any CSP-implementing site (regardless of the
> policy), and will be updating the wiki as well with more details as
> discussion progresses. Thanks for the feedback!
>
> -Sid
That's right. We will have an updated set of documentation published
very shortly (this week) and we'll post to the list as soon as it's
up.
Cheers,
Brandon
Florian Weimer
> are a common vector for XSS, e.g. <body onload="evil()">. However,
> sites will still be able to do event handling in the following ways:
> 1) setting the on<event> properties of an element, e.g. foo.onclick =
> myFunc;
> 2) using addEventListener, e.g. foo.addEventListener("click", myFunc,
> false);
>
> Of course, both methods would have to be used from within white-listed
> script files.
Are such script files still exposed across domains, as they used to
be? I'm wondering if it might be difficult to generate those scripts
for a highly dynamic page without leaking sensitive content.
There's also the question if this approach just moves the cross-site
scripting risk to direct injection into Javascript code. The proposal
does not really address this (which is not its fault), but CSP
restrictions might lead developers to rely increasingly on Javascript
code generation to add HTML attributes which are blocked.
FunkyRes
wrote:
>
> Actually, all event-handling HTML attributes will be blocked, as they
> are a common vector for XSS, e.g. <body onload="evil()">. However,
> sites will still be able to do event handling in the following ways:
but evil() can only exist as a javascript built-in function or as a
function defined in a white-listed source.
Sid Stamm
> There's also the question if this approach just moves the cross-site
> scripting risk to direct injection into Javascript code. The proposal
> does not really address this (which is not its fault), but CSP
> restrictions might lead developers to rely increasingly on Javascript
> code generation to add HTML attributes which are blocked.
Maybe I don't fully understand your concern, but I don't think we're
just shifting the attacks; many sites use the
JavaScript-to-attach-handlers technique already, and we're not enforcing
this policy for all sites -- just the ones who want to use CSP, and only
because we need to do this to be sure the policies are properly enforced.
Also, one of the desired features of CSP would be not only this
load-time blocking of the methods/attributes that make code from
strings, but also run-time enforcement too. The attributes that are
blocked by CSP at load-time are also not allowed to be added to the DOM
at run-time. So you can't just put "domElement.onclick =
'myArbitrary(function) {foo}';" into javascript, no code-from-strings
conversion is allowed at any time. An attacker has to inject actual
code into a site, and not just exploit an "eval()" or other
string-to-code conversion in the developer's JavaScript.
It's my belief that CSP will generally make attacks more difficult and
vulnerabilities harder to come by, not just different. In order to get
the on-click event handler to work, for instance, the developer has to
place an event handler function somewhere in the white-listed script
file and use JavaScript to attach it to DOM. The only obvious way an
attacker could inject different event handling code is through a MITM
attack or a direct injection to the server's data store that messes with
the JavaScript content being served. Since CSP is stopping JavaScript
from making code out of strings in the browser, the attacker must inject
stuff on the server side or in the network stream, and if he can do
that, it's game over anyway.
-Sid
Brandon Sterne
First, "evil()" is just a short way of expressing the idea of
"malicious JavaScript code". That placeholder doesn't have to
represent a single function call. You can replace it with any literal
malicious code if that helps your thinking about the model.
Also, even if a function is defined in a white-listed file, you still
will not be able to call it from within the protected document. The
general assumption is that *all* code within the top-level protected
document cannot be trusted, because it could have been injected by an
attacker. This includes even solitary function calls. CSP's solution
is to only trust code inside the white-listed script files. Hope this
is helpful.
Thanks,
Brandon
Florian Weimer
> It's my belief that CSP will generally make attacks more difficult and
> vulnerabilities harder to come by, not just different. In order to
> get the on-click event handler to work, for instance, the developer
> has to place an event handler function somewhere in the white-listed
> script file and use JavaScript to attach it to DOM.
Okay, let's try to make this more concrete. Suppose I've got a web
form, and want to add some client-side validation to it. With CSP,
the HTML will look a bit like this:
<form method="POT">
<input type=text" name="user" />
[more fields, some of them dynamically generated]
<input type="submit"/>
</form>
<script src="/js/lib.js" />
<script src="/js/dyn/Rjw7KbMX2sodKxXetyTSNugzJ" />
The first <script> is some library and is expected to be cached. The
second <script> installs the Javascript validation code. Given that
the form is dynamically generated, a static Javascript file won't do
it, especially if eval and textual event handlers are forbidden.
Maybe it's technically possible to create something which extracts a
description of the event handlers to attach from the contents of a
hidden input field in the form, but I don't think this will be the
approach preferred by developers.
Instead, Javascript will be generated by the same mechanisms that now
generate HTML. With a lot of work, you might be able to create a
validation library which is entirely guided by JSON (see above), but
again, I think this won't be the most favored approach. So we end up
with dynamically generated Javascript, and attackers will inject
Javascript directly, instead of injecting Javascript-carrying HTML
code into HTML documents.