Pádraic Brady wrote:
What does this mean? Escaping is not a small area of the problem - it's one of the biggest areas of the problem - potentially bigger than input sanitisation since invalid values are irrelevant to proper escaping which operates blindly by design. A lack of escaping impacts every single point in every shred of application output which contains data sourced from everything not literally defined in the current request and just one failure may be sufficient for an attacker to dump encoded Javascript into the browser to steal cookies, perform requests, track key presses, rewrite HTTPS links, attack browser extensions, and any number of other effects.
My whole point here is identifying WHAT needs 'escaping'. You can't simply 'escape' the output stream, you still want html tags to get out? I hope. So you need to filter what is acceptable and what isn't. Perhaps HTMLPurifier should be a requirement everywhere, but then you need to 'pre-process' the content so as to allow through the 'text' that you want to display which may well be an example of a XSS attack? You can only apply 'escape' to elements that you have identified as needing it and need to let through those that do not. It is the 'filtering' out of the material that needs processing that is the problem? And I have no doubt that someone will find a hole that allows them to sneak past the filtering?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
