Re: RFC: Implementing a core anti-XSS escaping class

From: Date: Wed, 19 Sep 2012 15:39:57 +0000
Subject: Re: RFC: Implementing a core anti-XSS escaping class
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-63142@lists.php.net to get a copy of this message
On 19/09/12 16:36, Pádraic Brady wrote:
Hi Steve,
Who's he? :)
Everybody knows Steve! :P I know at least 10!
The ESAPI API uses encodeForHTML, encodeForCss, etc. We can name these in a few different styles which would all be semantically correct but my own sentiment is often to keep the naming simple.
The naming is unclear just now though.
Than I suggest including "For" in all of them. escapeForHtml, escapeForUrl, etc. That should clear it up somewhat that we're not targeting whole blocks of HTML/JS/CSS. That still isn't clear enough, I think. escapeHTMLAttributeValue and escapeHTMLText. It needs to be clear what HTML context you're dealing with.
For example, I'd prefer escapeForCss vs escapeCSSStringLiteral though both would be valid English literal alternatives to escapeCss.
You can't just have escapeForCSS, you need two functions: one for CSS identifier names (.identifier, #identifier, etc.), and one for CSS strings (background-image: url('string'); or content: 'string')
Not really, the target here is breaking out of a CSS or HTML context. If you allow users to alter identifiers or properties than escaping is just wrong - you should be sanitising instead to make sure the CSS is still well formed and agrees to a whitelist of allowed ids/props. If property values or identifiers can't be escaped, what can? What do you mean?
Are you meaning in style="" or <style></style>? In which case, why have it? You can just use a bog-standard HTML escaping function.
Also, escapeForJS isn't very clear, you should explicitly specify you're escaping a string of text for a JavaScript string literal. I don't think you can escape JS identifier names.
JS is purely for literal values and not any JS variables/statements or anything else. Those can never ever be subject to any form of untrusted input. It needs to be clear it's a string literal though, and a literal at that. Otherwise it's a little unclear. Still, I'm more worried about the CSS.
-- Andrew Faulds http://ajf.me/

« previous php.internals (#63142) next »