3 ms·

tl;dr Stop allowing everything to be concatenated with everything else, and just because PHP tried bad solutions to a problem doesn't mean that problem is unsol

tl;dr Stop allowing everything to be concatenated with everything else, and just because PHP tried bad solutions to a problem doesn't mean that problem is unsolvable. > it was a disaster because the compiler isn't aware of the context the programmer is This is completely true, but the underlying cause is that everything is a string. As long as the "solution" is converting strings into strings (eg. magic quotes, escaping, etc.) they're doomed. At a previous job we modified the PHP interpreter to give user input a 'dirty bit'. Dirty bits spread to anything they touched (dirty . clean -> dirty, implode(dirty, [clean]) -> dirty, etc.). Trying to output dirty strings (to stdout, DBs, files, etc.) was a fatal error. Escaping functions unset the dirty bit. Escaping a non-dirty string was a fatal error. This worked quite well. > > introduce a proper API that can be used to filter all incoming data. > Things like magic quotes, etc. were tried. All failed because its a bad idea. Not really. Making everyone access GET/POST vars in the same way is a bad idea. Better to provide getter functions like "get_param_unsafe" and "post_param_unsafe" for this, then provide a bunch of common alternatives which provide escaping like "get_param_html", "post_param_quoted", etc. Even safety-conscious languages like Haskell know that there's no one-size-fits-all approach; but as long as you cover the basics and give scary names to your escape-hatches (eg. "unsafePerformIO", "unsafeCoerce", etc.) then it limits the damage. "unsafe" is basically a big red warning sticker, telling you to pay extra special attention to what's going on. It only ever occur in custom validation/sanitising code, eg. in the definition of "get_param_my_custom_format". If a codebase has "unsafe" all over the place, that's an alarm bell which says the code is dangerous and needs to be refactored to provide and use some safe APIs. > PDO isn't the answer. Meh, library problems. PDO shouldn't be baked into the language, but neither should anything else. > You can't magically make people do things correctly. Yes you can: you can make it impossible/very difficult to do it incorrectly. Again, stop allowing everything to be concatenated with everything else and this issue will be magically resolved. > Without knowing the context (say, expecting a date vs. markdown), it would be an awful idea. If only PHP were capable of providing some kind of "interface", which other code could "implement"...

opendais 12y ago
I think the problem here is you think it should be a language function and I think it should be an extensible external implementation. The problem is the blacksmith, not the tool. LOLPHP stuff is consistent in how it happens. It doesn't magically change. So, if you know it happens, you adjust and adapt. Its not wonderful but adding more magic is the opposite of the solution. The solution is to get rid of all the magic language features that don't work quite right and clean up the ones that do. > Meh, library problems. PDO shouldn't be baked into the language, but neither should anything else. That is kind of my point. All of this should be separate implementations. > tl;dr Stop allowing everything to be concatenated with everything else, and just because PHP tried bad solutions to a problem doesn't mean that problem is unsolvable. Provide evidence of a truly secure language with all potential contexts baked in. > Not really. Making everyone access GET/POST vars in the same way is a bad idea. Better to provide getter functions like "get_param_unsafe" and "post_param_unsafe" for this, then provide a bunch of common alternatives which provide escaping like "get_param_html", "post_param_quoted", etc. Quoting strings is not security. People will use that "post_param_quoted" just like magic quotes and everything else and fuck it up. > Yes you can: you can make it impossible/very difficult to do it incorrectly. Again, stop allowing everything to be concatenated with everything else and this issue will be magically resolved. Concatenating quoted strings to each other is an unsafe operation. So, no, you can't. > If only PHP were capable of providing some kind of "interface", which other code could "implement"... It does. There are security libraries you can use. Its not a language feature. PHP has repeatedly failed at attempting to add security-as-a-language-feature because its complicated, difficult, and most people won't understand it anyway.

opendais 12y ago

I think the problem here is you think it should be a language function and I think it should be an extensible external implementation. The problem is the blacksmith, not the tool. LOLPHP stuff is consistent in how it happens. It doesn't magically change. So, if you know it happens, you adjust and adapt. Its not wonderful but adding more magic is the opposite of the solution. The solution is to get rid of all the magic language features that don't work quite right and clean up the ones that do. > Meh, library problems. PDO shouldn't be baked into the language, but neither should anything else. That is kind of my point. All of this should be separate implementations. > tl;dr Stop allowing everything to be concatenated with everything else, and just because PHP tried bad solutions to a problem doesn't mean that problem is unsolvable. Provide evidence of a truly secure language with all potential contexts baked in. > Not really. Making everyone access GET/POST vars in the same way is a bad idea. Better to provide getter functions like "get_param_unsafe" and "post_param_unsafe" for this, then provide a bunch of common alternatives which provide escaping like "get_param_html", "post_param_quoted", etc. Quoting strings is not security. People will use that "post_param_quoted" just like magic quotes and everything else and fuck it up. > Yes you can: you can make it impossible/very difficult to do it incorrectly. Again, stop allowing everything to be concatenated with everything else and this issue will be magically resolved. Concatenating quoted strings to each other is an unsafe operation. So, no, you can't. > If only PHP were capable of providing some kind of "interface", which other code could "implement"... It does. There are security libraries you can use. Its not a language feature. PHP has repeatedly failed at attempting to add security-as-a-language-feature because its complicated, difficult, and most people won't understand it anyway.