Hi Steve,
Missed this one in the rush of emails...
> I echo this. I think some clearer names might help, I think something like
> these:
>
> escapeHTMLAttribute for attributes, escapeHTMLText for text inside <element>
> tags, escapeXMLAttribute and escapeXMLContent, escapeJSStringLiteral,
> escapeCSSIdentifier, and another needs adding (for url('*') things),
> escapeCSSStringLiteral.
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.
For example, I'd prefer escapeForCss vs escapeCSSStringLiteral though
both would be valid English literal alternatives to escapeCss.
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
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
