3 ms·

> Security. PHP in itself is not insecure and it is obviously possible to write perfectly fine and secure applications with PHP. But PHP decided to implement an

> Security. PHP in itself is not insecure and it is obviously possible to write perfectly fine and secure applications with PHP. But PHP decided to implement an quite naive approach about security and doesn´t support the developer too much in writing secure code. Its the same f'n approach every other language took. "Offload it to libraries". > To be fair everybody was naive about web security in the 90s. So there are a not a lot of features available in PHP that actively support you with writing secure code. > Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper API that can be used to filter all incoming data. Actually, they tried to implement the kind of "security features" you suggest and it was a disaster because the compiler isn't aware of the context the programmer is. Things like magic quotes, etc. were tried. All failed because its a bad idea. This suggestion is horribly ignorant and misguided. > Database. PHP support a ton of different database API. Some of them are very old but they are inconsistent to use. Everything should be standardized so that only one OO interface exists. I personally would use PDO as a starting-point here. Give up MYSQL ASYNC? Fuck No. I am not re-writing entire libraries into C to regain access to something I need. There are also differences between Postgres and MySQL implementations, etc. for reasons other than "Oh we felt like it". There needs to be one, consistent driver for each database. PDO isn't the answer. The fundamental issue seems to be the author is ignorant of the fact there are reasons some of this stuff does or doesn't exist. > Remove most of the compile and runtime config options. All PHPNEXT runtime environments should be as similar and stable as possible. Fuck no. That is why Dev & Ops get together and pick "We want combination X to work with, godspeed!". > The database situation is a mess so a lot of people still don´t use prepared statement which leads to possible SQL injection. That is the carpenter failing to use the hammer correctly issue. You can't magically make people do things correctly. > And filtering incoming data for XSS and other problems has to be done relatively manually. There are extensions and libraries available to help with all this problems but they are not part of the language/runtime core or are incomplete. Of course it does. Without knowing the context (say, expecting a date vs. markdown), it would be an awful idea. Security is entirely about the context and expectations. You can't do a one-size-fits-everyone-for-all-uses approach and build into the language. That is insane and doomed to fail. PHP tried it before.

chriswarbo 12y ago
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.

chriswarbo 12y ago

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.