On 31 July 2013 15:01, Tyler Romeo <tylerromeo(a)gmail.com> wrote:
On Wed, Jul 31, 2013 at 8:38 AM, Happy Melon
<happy.melon.wiki(a)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