On 19/09/12 18:48, Pádraic Brady wrote:
I think we're running into being overly prescriptive. Escaping can
never, by definition, apply to anything that isn't a value string or
integer, i.e. anything that is capable of altering the meaning of the
HTML/Javascript or CSS into which its inserted. The original function
names applied to specific escaping "strategies" rather than the actual
locations that that strategy was useful for. There is only one HTML
escaping strategy, one Javascript escaping strategy, etc.
Ah, good point. Although, note, the HTML escaping strategy must
therefore cover ' and " in that case.
<style>
body {
background-color: <? echo $e->escapeCss('white'); ?>
}
</style>
In the above we escape the value so that an attacker cannot "breakout"
into the CSS propery setting context to create new styles or
identifier blocks. So it applies only to the values of properties and
nothing else. If anything else is allowed to be subject to user input
- then escaping becomes moot because you now need to perform CSS
sanitisation to a whitelist to prevent the injection of phishing or
clickjacking attacks.
The documentation (if not the RFC) should be the place to emphasise
when and where to use escaping functions.
I think that was a little misunderstanding, you're right we don't need
to escape identifier names here, though. I thought you meant we
shouldn't be escaping anything going into CSS, and it should be
sanitised instead.
Again, I think being overly prescriptive is unnecessary. It has
semantic value, of course, but the game is already lost if the user
isn't aware of where to safely apply escaping (a different problem to
applying the correct encoding over the wrong encoding). I think we're
bumping into a slightly different area of education here. Once users
know where escaping applies, the names even in their shorter forms are
fairly obvious as to which context they apply to. I think that
specific education is better served with good quality documentation
and examples (I'm all for docs with a dose of reality).
Fair enough.
Paddy
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
