On 31 July 2013 15:01, Tyler Romeo tylerromeo@gmail.com wrote:
On Wed, Jul 31, 2013 at 8:38 AM, Happy Melon <happy.melon.wiki@gmail.com
wrote:
Deliberately using a function which reduces the security of your application to relying on everyone choosing the correct type of quotes is definitely asking for trouble.
I don't see how this is an issue. htmlspecialchars() can cause an XSS vulnerability if you pass it the wrong ENT_ constant. Should we just stop using htmlspecialchars() in case developers pass the wrong constant?
Yes, IMO, it should be abstracted away with a carefully-written wrapper function that bridges the semantic gap between "I want to do some character conversions" and "I want to make this text safe to echo to the browser", but that's just the point. Of course there are plenty of language features you can point to that open up pitfalls; each one having its own severity and ease-of-discovery. htmlspecialchars() has a medium severity and very easy discovery, and it's a problem that's easy to eliminate by abstracting the call to ensure it's always given the proper arguments. My example was to disprove your point that assert() with string arguments is not as bad as eval(); it is, for exactly the same reasons. Of course it's possible to use eval() safely, just like any other construct, but general consensus is that eval()'s security holes are severe enough and difficult-to-spot enough to warrant strongly discouraging its use, and there is no reason not to treat assert()-with-string-args the same way.
--HM