3 ms·
> because developers thought they can take input in one format, "escape" it enough, sprinkle with addslashes and things will work But that is exactly what the
by Jensson 4y ago
> because developers thought they can take input in one format, "escape" it enough, sprinkle with addslashes and things will work
But that is exactly what the solution is, you escape user strings, there is no other solution to the problem. Either you do it yourself or you use a library to do it, but the end result is the same, I'm not sure why you think this is impossible to do when it has been done successfully for decades.
The problem is that many fail to escape strings correctly, not that it is impossible to do.
- stefan_ 4y agoNo, escaping is precisely not what you do. Escaping is the hack you add because you didn't consider separating code and data in the first place. Do not offer an API that mixes these two things.
- blowski 4y agoWhat about parameterised queries?
- friendzis 4y agoEscaping/sanitizing is required when providing "command+data" inputs to external engines. It's error prone. One needs rigorous escaping done just before the output. Multiple escapes can clash. > But that is exactly what the solution is, you escape user strings, there is no other solution to the problem The correct way is to use interfaces that allow separation of command and data inputs. With SQL prepared statements are used. With HTTP data is put in request body or at least after the ?. With HTML data URLs are used. And so on. > The problem is that many fail to escape strings correctly, not that it is impossible to do. I really don't want to argue whether escaping correctly is possible at all. Every possible substring sequence, escaping attempts included, that can be interpreted as command by the interpreting system must be accounted for. I would rather avoid the problem altogether, if possible.