5 ms·
In all seriousness, shouldn't all the frameworks just have some validation built in? Being that this is such a "global" WTF problem. I would love to be able to
by unabst 10y ago
In all seriousness, shouldn't all the frameworks just have some validation built in? Being that this is such a "global" WTF problem.
I would love to be able to say ini_set('sanitize_rest', true) and deal with errors that might result from that knowing at least the strings are safe. Or have functions like sanitize_string($str) and have the documentation encourage it everywhere. I mean, aren't we all just implementing those on our own anyway?
I know that obviously there are already functions for type checks etc, but the idea is to make it even easier, more obvious, and functions directly targeting the problem, even if they are mere aliases.
When a mistake is easy, the solution should be made easier.
- kijin 10y agoPHP has already tried automatic sanitization with magic_quotes_gpc, and the results were far from secure. It is not possible to have a single sanitize() function that renders a string safe for every possible context, and to try to provide one results in nothing but complacency and false sense of security. Escaping for SQL is different from escaping for HTML, and even if you escaped a string for both, some idiot is going to echo it inside an inline script or a CSS attribute. Sanitize for all of them, and you begin to seriously mangle those strings. Oh, and it might still be ineffective against directory traversal. I've seen plenty of PHP users who think they're clever because they wrote a function that applies every single escaping function in a row, not realizing them some of them undo one another's work. Selectively unescaping after the fact is even more fun. The only thing I can think of that could render a string absolutely safe in every context is intval(), but then you don't have a string anymore, and I suspect that even that can be abused with unexpected zeroes and negative values.
- unabst 10y agoRight. I absolutely get this argument, except, the alternative to idiots misusing the tools is for those same idiots to start with no tools! And they're going to somehow implement and upload what they're building anyway...
- stephenr 10y agoPhp has an entire extension devoted to sanitising and validating input data. It can't be a simple on/off because php can't guess what your inputs are or what you want to use them for.
- deleted 10y ago[deleted]
- stephenr 10y agoA one-size-fits-all cannot work. Ever. For an SQL-based DB (i.e. where the data mixes with the logic in the query) you should be using parameterised queries anyway. For general data sanitisation/validation you should look at the filter_* functions.
- aseipp 10y agoWhat does this nonsense reply even mean? Nobody is talking about one-size-fits-all. People are talking about mitigating some stupid default behavior in a language. The suggestion "You're doing it wrong" just feeds into his point (that you can even get something this straightforward wrong in the first place indicates, maybe, you should put a fence there to warn people). Programmers have so much stockholm syndrome it's unbelievable.
- stephenr 10y ago> Nobody is talking about one-size-fits-all. > I would love to be able to say ini_set('sanitize_rest', true) and deal with errors that might result from that knowing at least the strings are safe. How is a magic ini setting to "make Strings safe" not a one-size-fits-all? > People are talking about mitigating some stupid default behavior in a language. What stupid default behaviour? Giving you data as its received and tools to validate/sanitize it as required?