Re: RFC: Implementing a core anti-XSS escaping class
| From: | Andrew Faulds | 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:
Everybody knows Steve! :P I know at least 10!Hi Steve,Who's he? :)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.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.
Are you meaning in style="" or <style></style>? In which case, why have it? You can just use a bog-standard HTML escaping function.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?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')
-- Andrew Faulds http://ajf.me/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.