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

On 19/09/12 15:07, Pádraic Brady wrote:

Hi Steve, Who's he? :)

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.

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')

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.

It's also worth bearing in mind that these escaping functions are distinct and separate from the concept of sanitisation or a sanitising filter. For each escaping option there is a sanitisation alternative where untrusted input (whether from a user, database or 3rd party service) contains markup you want to allow through "unescaped". For example, a feed aggregator would need to output HTML from a 3rd party feed and it may contain URLs that also need to be validated. HTML, of course, has HTMLPurifier - easily the best HTML sanitiser. URLs must always be validated to a known good whitelist (not filter_var() only). CSS can also be sanitised if the user has access to properties and not just the property values. Paddy

-- Andrew Faulds http://ajf.me/