3 ms·
> SANITIZE ALL USER INPUT. ALWAYS. NO EXCEPTIONS. I really don't like that word. Or "filter", "clean" or whatever people call it. It implies that you can some
by troels 16y ago
> SANITIZE ALL USER INPUT. ALWAYS. NO EXCEPTIONS.
I really don't like that word. Or "filter", "clean" or whatever people call it.
It implies that you can somehow run a variable through a filter and scrub of all the evilness. But that is not how to deal with the problem. What need be done, is to encode strings properly when embedding them in a context, that is interpreted in some other context. For example encode entities when inserting into html or urlencode when inserting into a url.
Bottom line is - This has nothing to do with user input. It has to do with how you output data.
- onteria 16y agoIf you're preventing SQL injection, you do need to run the variable through a filter (mysql_real_escape_string, parameter binding, etc.) in order to prevent a successful attack. The other issue is that if I encode entities when inserting html, that means I have to call this on every page view. For simple strings that's not too big a deal, but if I have a lot of content, this gets resource intensive pretty fast for larger scale sites with lots of people hitting a page at once. In this case I'd rather due the encoding once, which handles a majority of cases.
- prodigal_erik 16y agoEncoding is dirt cheap. You probably pay more just for a TCP stack that isn't perfectly tuned for your workload. And you can't pre-encode a string without baking in bad assumptions that you know how it may ever be used. You're going to regret having your data store polluted with HTML-specific encoding as soon as you build an API or integrate a third-party tool (e.g., analytics or sales support), because they will need either raw values or some different encoding than HTML text (SGML entities).