Forums | MacLife

http://homepage.mac.com/mpeters/misc/cs … ss.php.txt

constructive criticism very welcome.

The idea is spawned from:
http://people.mozilla.org/~bsterne/cont … ty-policy/

What the class is suppose to do is enforce a content security policy server side before the content is sent to the browser. The reason for doing it server side is that even when the CSP recommendation is finally adopted, it will be some time before it hits significant market penetration in browsers because people will have to be running fresh versions of their browser (or decide to install an add-on) to benefit.

What the class is suppose to do is yank out parts of the web page that would violate the defined CSP and thus not be rendered by the browser anyway.

I do go a little bit beyond that by yanking out anything that is suppose to child of head but isn't and yanking out extra elements that are only suppose to occur once (IE title and head) though that last one is currently broken because the of the way a DOMNodeList works (I know how to fix it).

I also have a disagreement with current CSP recommendation which states that anything in an event attribute won't be executed. I think that's overbearing, if you are going to allow scripting at all then allow the event attributes to trigger a function. So - the class has a whitelist you can set for event attributes you want to allow. However, functions called in those event attributes can not have any arguements [IE onsubmit="return validate('foo');" gets filtered to onsubmit="return validate();" ]

Since the script element is not allowed to have children in a CSP page, any function in an event attribute has to either be a standard js function or properly defined in an external .js file from a whitelisted host, allowing arguments can be dangerous but removing the ability to use event attributes all together I think is taking things too far. But if you really want current CSP compat, simply don't define a whitelist of event attributes you allow.

-=-

Right now the class only deals with the cases where a CSP policy is set to "none" - I haven't yet written the functions to make sure src attribute on allowed elements matches the white list, that's going to be a little bit tricky because CSP accepts wildcards in the whitelist (as it should) - I'll figure it out, but first I want to thoroughly test what I have.

Since html/xhtml is structured data, I figured the best way to write such a filter is with a tool designed to work with structured data, my good friend DOMDocument. Makes it much easier to ensure I'm not mutilating content, easier to catch filter dodging, etc.

So - the class only works on a DOMDocument object.
And yes, that means the page needs to be fully constructed before any of it is sent to browser, but given the stateless nature of http that really is the proper way to do it anyway.

Example usage -

get your data into a DOMDocument - IE

$mydoc = new DOMDocument("1.0","UTF-8");
$mydoc->preserveWhiteSpace = false;
$mydoc->formatOutput = true;
$mydoc->loadHTML($yourhtml); // you should use loadXML for well formed xhtml

then

$sanitized = new cspfilter;
$sanitized->csp['allow'] = "none";
$sanitized->csp['img-src'] = "self";
$sanitized->csp['script-src'] = "scripts.example.com evil.haxor.org";
$sanitized->httphost = "www.mydomain.edu";
$sanitized->inputDom($mydoc);
$sanitized->processData();

The class will then alter $mydoc - simply serve it via

print $mydoc->saveHTML(); // use saveXML() for xhtml