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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
