5 ms·

In defense of PHP, this is probably due to simplicity. PHP got many people started with server side web development, and docs were supposed to be "simple". Th

In defense of PHP, this is probably due to simplicity. PHP got many people started with server side web development, and docs were supposed to be "simple". The thinking back then probably was "if we make the example more complicated, we will loose people", which was probably even true for the target audience.

prox 5y ago
When I started like this, I always followed up with a google query for securing what I did. Not the best way to learn, but as you say, it got you started.
pdimitar 5y ago
I don't see this as a defense, I am seeing it as a way to reach to more programmers, and basic security practices be damned in the process. I have to wonder: what did these people have to gain if PHP got popular (which it did)? That's an egotistical way of popularizing your language.
- tored 5y ago
  Now do C.
  - pdimitar 5y ago
    I know right. That's why I'm not doing C anymore, for 10+ years now.
    - tored 5y ago
      Was Dennis Ritchie egotistical for popularizing C? He would have known all the security flaws in it, right?
      - pdimitar 5y ago
        Very disagreed with your analogy. By the time those PHP tutorials were written, SQL injection attacks were already known. So not sure what you're trying to push here but I refuse to participate.
        tored 5y ago
        Still to this day you have free-after-use bugs in the Linux kernel, about 20% of all known bugs in the kernel. How is this not comparable?
        pdimitar 5y ago
        It is comparable, that's why I'm moving to Rust. Hence I said I don't want to participate simply because I am not defending C either. It played its role and it's time for it to be phased out.
      - NationalPark 5y ago
        Which MySQL library did Ritchie wrap back in 1972?
        tored 5y ago
        https://news.ycombinator.com/item?id=27959145 https://news.ycombinator.com/item?id=27959145
        NationalPark 5y ago
        My bad, which version of Linux should Ritchie have been auditing in 1972?
Cthulhu_ 5y ago
I see what you mean, but at the same time, back then just getting a working PHP environment up and running was complicated enough - PHP, Apache, MySQL, and you had to get them all working together. If it was about accessibility, they should have made an easy installer and even offered cheap hosting themselves I think. As for SQL injection, were prepared statements even a thing back then? Either way they should never have allowed and normalized string concatenation to build up SQL queries.
- tored 5y ago
  There have existed multiple installer projects for PHP, Apache & MySQL on Windows for two decades. Mysqli driver was released with PHP 5.0 in 2004, it has prepared statements.
- piokoch 5y ago
  "just getting a working PHP environment up and running was complicated enough" Hah, that was one of the biggest strength of PHP stack - it was not complicated; on you MS Windows machine it was enough to install some wammp/xammp, etc. PHP/MySQL/Apache bundle, open editor, put in the first line <? and start coding. On production, typically some shared hosting (cheap! Another said stack advantage) this was already installed, so it was sufficient to FTP files over there and be done (one more advantage). There was no other comparable stack in terms on simplicity and being able to do something quickly. I believe there is none today, only PHP stack matured, so there are frameworks, etc. Yes, there were security concerns, but still much less comparing to its server-side predecessor CGI scripts (better known today as AWS lambdas or "serverless").
  - jimmaswell 5y ago
    Configuring the "plugins" and everything to get PHP working on Apache on Linux can be complicated and annoying if you're not already familiar with the process.
- zzzeek 5y ago
  > As for SQL injection, were prepared statements even a thing back then? wow. yes, prepared statements have been a thing since there were relational databases. but also, (server side) prepared statements are not required in order to use SQL with bound parameters. the binding can occur just as easily on the client side, and this is in fact quite common. the point is that the programmer is not manually deciding whether or not to escape a parameter on a query-by-query basis, the process is automated.
deleted 5y ago
[deleted]
mxd3 5y ago
The fact that it got newbies started doesn't mean it was built for newbies. I think you're making too many assumptions here.
chriswarbo 5y ago
> In defense of PHP, this is probably due to simplicity I don't consider this to be a good defence; in fact, I'd argue that makes PHP itself insecure. I like to think of secure coding in terms of the 'path of least resistance' for a lazy/busy/inexperienced developer. If doing things securely makes life harder, things will be done insecurely. We don't need to make the secure approach easier in absolute terms; we can just make the insecure approaches more painful. In this case: have database functions require arguments of an 'SQL' type, rather than strings; make it easy to write literal SQL values; make it easy to parameterise SQL values; make it as hard as possible to convert a string value to an SQL value, e.g. bury it in some deep namespace hierarchy, with a long and scary-sounding name, require a config value to be enabled (or even make it a compiler flag!), etc. This way, the docs (plus stack overflow, blog posts, etc.) don't have to choose between showing a secure approach or showing the simplest approach; since they are the same!
- michaelmior 5y ago
  > make it easy to parameterise SQL values It usually is easy to parameterize things like values used in WHERE clauses. It's often much harder to work with dynamic query conditions (e.g. optional filters on a particular column). I don't believe I've seen an approach that does this in a way that can provably provide any sort of safety guarantee.
  - chriswarbo 5y ago
    Do you have an example? I can only imagine three scenarios: - SQL logic. We should be able to write this as a literal query, parameterised as needed, e.g. (made up syntax) query( addParam( "MyParam", $myParam, SQL"SELECT foo FROM tbl WHERE @MyParam IS NULL OR bar = @MyParam" ) ) - PHP logic. This is just ordinary control flow, like anything else, e.g. query( ($myParam === null) ? SQL"SELECT foo FROM tbl" : addParam("MyParam", $myParam, SQL"SELECT foo FROM tbl WHERE bar = @MyParam") ) - A mixture of SQL logic and PHP logic. This seems inherently unsafe to me, so it's not surprising that safety guarantees can't be proven. My point is that such things should be be made difficult ("artificially", if needed), such that nobody would choose to go down that route when another option is available.

prox 5y ago

When I started like this, I always followed up with a google query for securing what I did. Not the best way to learn, but as you say, it got you started.

pdimitar 5y ago

I don't see this as a defense, I am seeing it as a way to reach to more programmers, and basic security practices be damned in the process. I have to wonder: what did these people have to gain if PHP got popular (which it did)? That's an egotistical way of popularizing your language.

tored 5y ago
Now do C.
- pdimitar 5y ago
  I know right. That's why I'm not doing C anymore, for 10+ years now.
  - tored 5y ago
    Was Dennis Ritchie egotistical for popularizing C? He would have known all the security flaws in it, right?
    - pdimitar 5y ago
      Very disagreed with your analogy. By the time those PHP tutorials were written, SQL injection attacks were already known. So not sure what you're trying to push here but I refuse to participate.
      - tored 5y ago
        Still to this day you have free-after-use bugs in the Linux kernel, about 20% of all known bugs in the kernel. How is this not comparable?
        pdimitar 5y ago
        It is comparable, that's why I'm moving to Rust. Hence I said I don't want to participate simply because I am not defending C either. It played its role and it's time for it to be phased out.
    - NationalPark 5y ago
      Which MySQL library did Ritchie wrap back in 1972?
      - tored 5y ago
        https://news.ycombinator.com/item?id=27959145 https://news.ycombinator.com/item?id=27959145
        NationalPark 5y ago
        My bad, which version of Linux should Ritchie have been auditing in 1972?

Cthulhu_ 5y ago

I see what you mean, but at the same time, back then just getting a working PHP environment up and running was complicated enough - PHP, Apache, MySQL, and you had to get them all working together. If it was about accessibility, they should have made an easy installer and even offered cheap hosting themselves I think. As for SQL injection, were prepared statements even a thing back then? Either way they should never have allowed and normalized string concatenation to build up SQL queries.

tored 5y ago
There have existed multiple installer projects for PHP, Apache & MySQL on Windows for two decades. Mysqli driver was released with PHP 5.0 in 2004, it has prepared statements.
piokoch 5y ago
"just getting a working PHP environment up and running was complicated enough" Hah, that was one of the biggest strength of PHP stack - it was not complicated; on you MS Windows machine it was enough to install some wammp/xammp, etc. PHP/MySQL/Apache bundle, open editor, put in the first line <? and start coding. On production, typically some shared hosting (cheap! Another said stack advantage) this was already installed, so it was sufficient to FTP files over there and be done (one more advantage). There was no other comparable stack in terms on simplicity and being able to do something quickly. I believe there is none today, only PHP stack matured, so there are frameworks, etc. Yes, there were security concerns, but still much less comparing to its server-side predecessor CGI scripts (better known today as AWS lambdas or "serverless").
- jimmaswell 5y ago
  Configuring the "plugins" and everything to get PHP working on Apache on Linux can be complicated and annoying if you're not already familiar with the process.
zzzeek 5y ago
> As for SQL injection, were prepared statements even a thing back then? wow. yes, prepared statements have been a thing since there were relational databases. but also, (server side) prepared statements are not required in order to use SQL with bound parameters. the binding can occur just as easily on the client side, and this is in fact quite common. the point is that the programmer is not manually deciding whether or not to escape a parameter on a query-by-query basis, the process is automated.

deleted 5y ago

[deleted]

mxd3 5y ago

The fact that it got newbies started doesn't mean it was built for newbies. I think you're making too many assumptions here.

chriswarbo 5y ago

> In defense of PHP, this is probably due to simplicity I don't consider this to be a good defence; in fact, I'd argue that makes PHP itself insecure. I like to think of secure coding in terms of the 'path of least resistance' for a lazy/busy/inexperienced developer. If doing things securely makes life harder, things will be done insecurely. We don't need to make the secure approach easier in absolute terms; we can just make the insecure approaches more painful. In this case: have database functions require arguments of an 'SQL' type, rather than strings; make it easy to write literal SQL values; make it easy to parameterise SQL values; make it as hard as possible to convert a string value to an SQL value, e.g. bury it in some deep namespace hierarchy, with a long and scary-sounding name, require a config value to be enabled (or even make it a compiler flag!), etc. This way, the docs (plus stack overflow, blog posts, etc.) don't have to choose between showing a secure approach or showing the simplest approach; since they are the same!

michaelmior 5y ago
> make it easy to parameterise SQL values It usually is easy to parameterize things like values used in WHERE clauses. It's often much harder to work with dynamic query conditions (e.g. optional filters on a particular column). I don't believe I've seen an approach that does this in a way that can provably provide any sort of safety guarantee.
- chriswarbo 5y ago
  Do you have an example? I can only imagine three scenarios: - SQL logic. We should be able to write this as a literal query, parameterised as needed, e.g. (made up syntax) query( addParam( "MyParam", $myParam, SQL"SELECT foo FROM tbl WHERE @MyParam IS NULL OR bar = @MyParam" ) ) - PHP logic. This is just ordinary control flow, like anything else, e.g. query( ($myParam === null) ? SQL"SELECT foo FROM tbl" : addParam("MyParam", $myParam, SQL"SELECT foo FROM tbl WHERE bar = @MyParam") ) - A mixture of SQL logic and PHP logic. This seems inherently unsafe to me, so it's not surprising that safety guarantees can't be proven. My point is that such things should be be made difficult ("artificially", if needed), such that nobody would choose to go down that route when another option is available.