8 ms·

While this discussion boils down to the efficiency of the underlying regex engines for PHP and Rust, it does highlight (to me) why PHP is so popular: in the han

by osrec 7y ago

While this discussion boils down to the efficiency of the underlying regex engines for PHP and Rust, it does highlight (to me) why PHP is so popular: in the hands of average programmers, PHP is quick to write and fast (enough) to execute. I personally believe it's ubiquity is well-deserved, and I actually like it as a language despite all its quirks (which exist in almost every language I've come across)!

Avamander 7y ago
I don't like it from the security perspective, looking at just how many vulnerabilities PHP-based software has had, it's too trivial to create a XSS, SQLi, CSRF, LFI, RCE and many other classes of vulnerabilities. I think there are better options out there than on average give better results. Maybe it's just incredible selection bias I'm encountering \shrug.
- delfinom 7y ago
  But plenty of those vulnerabilities are not the fault of the language but the frameworks written by others. You can just as easily create SQL injection attacks in a Rust program or Ruby program. You can just as easily introduce XSS/CSRF problems in any of them. Etc.
  - beatgammit 7y ago
    > You can just a easily create SQL injection attacks in a Rust program I disagree, mostly on the grounds that string concatenation isn't very convenient, so it tends to be easier to do things "the right way" instead of hacking things together. Yes, you can do string concatenation using something like `format!(...)`, but at that point it's really similar to the correct solution that it's not really what you'd reach for by default. And yeah, the community here is a huge part of it, and IMO languages can and should be judged by their communities. If a language's community promotes insecure solutions, that's a language that I don't want to use at my company because I don't want my employees following that example.
  - Avamander 7y ago
    If the majority of frameworks for a language are vunerable it's the language's fault. Python definitely doesn't have that issue, Rust and Go don't either.
    - francislavoie 7y ago
      > majority of frameworks for a language are vunerable Where's your proof? Modern PHP frameworks are secure by default.
      - Avamander 7y ago
        We're talking about the majority of frameworks that are being used, not about some newer versions 0.1% use. In the end arguing won't get neither of us anywhere, I get my livelihood from testing vulnerable software and you can keep writing software in PHP.
        jtreminio 7y ago
        Majority of frameworks in use are: Symfony Laravel CodeIgniter CakePHP Yii Zend Slim All of these can (and recommend) using either PDO with named parameters, or a full ORM for SQL work. Most came packaged with a PDO (Doctrine, mostly) by default but have always supported whatever you wanted to use. Write shit code, win shit prizes.
- muglug 7y ago
  It’s really easy to write PHP, which means that people who don’t know about escaping input write PHP. While there are some web-focussed languages (vs frameworks) that deliberately make it hard for you to write that sort of code, barely anyone uses them.
  - colshrapnel 7y ago
    "escaping input" is a notorious delusion. And a bad one. - it is not "input" must be treated, but, so to say - output. It's the destination that matters, not the source. By the time you get the input, you have no idea how and where it will be used. You can tell it right before the output (or, rather, better to call it "use") only. Say, you've got some input that didn't pass the verification and you will have to display it back in the HTML form. And if you already "escaped" it for SQL, it will be malformed. And vice-versa. Moreover, any data must be formatted properly before use, not just something that you tagged as "input". - the word treated above is for a reason. Because the term "escaping" suggests some certain routine in PHP, which is the actual reason for numerous SQL injections.
    - muglug 7y ago
      You're right, my wording was inexact - we must always escape strings that can be controlled in some fashion by the user. I'm working on comprehensive taint analysis for PHP[0], and I'm spending a bunch of time thinking about how to automatically detect those dirty strings. [0] https://psalm.dev/articles/psalm-3-and-a-half#taint-analysis https://psalm.dev/articles/psalm-3-and-a-half#taint-analysis
  - horizone 7y ago
    > It’s really easy to write PHP, which means that people who don’t know about escaping input write PHP. Not trying call you out on this point, more it made me laugh. Our lead developer strips out characters that break his XML importer (lets just say they are standard common characters, heck, he changes chr(13) to a string so he can switch it back later because he doesn't know how to handle multiple lines in an XML value). People who don't know how to escape inputs / actually handle data properly are in every language. We cringe on a daily basis.
- deleted 7y ago
  [deleted]
- meritt 7y ago
  Your argument is a form of survivorship bias. You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. People were writing sloppy PHP before CSRF and XSS were even invented. Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written. You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation where programmers can't move fast enough in adding it to their stack. Data exfiltration is no longer a flaw but a feature.
  - Avamander 7y ago
    > People were writing sloppy PHP before CSRF and XSS were even invented. It is very very easy to write sloppy PHP, definitely easier than in many other languages and default frameworks. > You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. P I'm very aware of them, basically none have (had) as many high-impact vulns as PHP-based stuff does. > Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written. You're not acknowledging the orders of magnitudes difference between the impact of an usual PHP vuln and those you listed. > You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation The flaws in others are a very poor excuse for flaws in a thing itself.
biggestdecision 7y ago
PHP isn't popular because it's easy, it's popular because for a long while it was the only viable language for developing web applications.
- wvenable 7y ago
  Indeed. I think most developers don't understand how amazing PHP was compared to the competition and just how fast it acquired new features during those early years. It was a scripting engine with a such a thin layer of C that it could easily and quickly incorporate the huge number of open source C libraries that existed at the time.
  - osrec 7y ago
    While your observation is true to some degree, I do remember ASP, Cold fusion, CGI and a few other more obscure technologies way back when. Perhaps I was quite late to the party though - I only started programming in 1999 (got a computer for my 11th birthday!) - so I'm not sure what it was like before then.
    - javagram 7y ago
      ASP and ColdFusion both required license fees at the time I believe (asp the Windows server license and CF of course the CF license) CGI just would run any type of script. Originally that was typically Perl but PHP surpassed Perl for a variety of reasons. PHP could be run either through CGI or through mod_php in Apache. There was also a mod_perl I believe and a few others but php is what web hosts typically installed in the early 2000s.
      - im3w1l 7y ago
        Why did php beat perl?
        horizone 7y ago
        Personally, I switched from Perl to PHP around 2002 (I could be wrong with the year) as I wanted to move from flat file dbs to MySQL. I wouldn't say that it beat Perl, it was just made web development more accessible. I still wrote in Perl after that, but for server side scripting (processing, cleanup etc).
bjoli 7y ago
The same is true for python. I spent some time trying to write a CSV parser in guile scheme that was as fast as python's (mistakenly believing that python's CSV parser was actually written in python). I wrote a fast-ish streaming FSM-parser (about 100loc) but only managed to be about 1.7x as fast as python's CSV module. Browsing the python source I realised that the python parser was written in optimised and nicely buffered C. I could probably compete with python if I used guile's lower level C-procedures, but I sort of lost interest after that :)

by osrec 7y ago

Avamander 7y ago

I don't like it from the security perspective, looking at just how many vulnerabilities PHP-based software has had, it's too trivial to create a XSS, SQLi, CSRF, LFI, RCE and many other classes of vulnerabilities. I think there are better options out there than on average give better results. Maybe it's just incredible selection bias I'm encountering \shrug.

delfinom 7y ago
But plenty of those vulnerabilities are not the fault of the language but the frameworks written by others. You can just as easily create SQL injection attacks in a Rust program or Ruby program. You can just as easily introduce XSS/CSRF problems in any of them. Etc.
- beatgammit 7y ago
  > You can just a easily create SQL injection attacks in a Rust program I disagree, mostly on the grounds that string concatenation isn't very convenient, so it tends to be easier to do things "the right way" instead of hacking things together. Yes, you can do string concatenation using something like `format!(...)`, but at that point it's really similar to the correct solution that it's not really what you'd reach for by default. And yeah, the community here is a huge part of it, and IMO languages can and should be judged by their communities. If a language's community promotes insecure solutions, that's a language that I don't want to use at my company because I don't want my employees following that example.
- Avamander 7y ago
  If the majority of frameworks for a language are vunerable it's the language's fault. Python definitely doesn't have that issue, Rust and Go don't either.
  - francislavoie 7y ago
    > majority of frameworks for a language are vunerable Where's your proof? Modern PHP frameworks are secure by default.
    - Avamander 7y ago
      We're talking about the majority of frameworks that are being used, not about some newer versions 0.1% use. In the end arguing won't get neither of us anywhere, I get my livelihood from testing vulnerable software and you can keep writing software in PHP.
      - jtreminio 7y ago
        Majority of frameworks in use are: Symfony Laravel CodeIgniter CakePHP Yii Zend Slim All of these can (and recommend) using either PDO with named parameters, or a full ORM for SQL work. Most came packaged with a PDO (Doctrine, mostly) by default but have always supported whatever you wanted to use. Write shit code, win shit prizes.
muglug 7y ago
It’s really easy to write PHP, which means that people who don’t know about escaping input write PHP. While there are some web-focussed languages (vs frameworks) that deliberately make it hard for you to write that sort of code, barely anyone uses them.
- colshrapnel 7y ago
  "escaping input" is a notorious delusion. And a bad one. - it is not "input" must be treated, but, so to say - output. It's the destination that matters, not the source. By the time you get the input, you have no idea how and where it will be used. You can tell it right before the output (or, rather, better to call it "use") only. Say, you've got some input that didn't pass the verification and you will have to display it back in the HTML form. And if you already "escaped" it for SQL, it will be malformed. And vice-versa. Moreover, any data must be formatted properly before use, not just something that you tagged as "input". - the word treated above is for a reason. Because the term "escaping" suggests some certain routine in PHP, which is the actual reason for numerous SQL injections.
  - muglug 7y ago
    You're right, my wording was inexact - we must always escape strings that can be controlled in some fashion by the user. I'm working on comprehensive taint analysis for PHP[0], and I'm spending a bunch of time thinking about how to automatically detect those dirty strings. [0] https://psalm.dev/articles/psalm-3-and-a-half#taint-analysis https://psalm.dev/articles/psalm-3-and-a-half#taint-analysis
- horizone 7y ago
  > It’s really easy to write PHP, which means that people who don’t know about escaping input write PHP. Not trying call you out on this point, more it made me laugh. Our lead developer strips out characters that break his XML importer (lets just say they are standard common characters, heck, he changes chr(13) to a string so he can switch it back later because he doesn't know how to handle multiple lines in an XML value). People who don't know how to escape inputs / actually handle data properly are in every language. We cringe on a daily basis.
deleted 7y ago
[deleted]
meritt 7y ago
Your argument is a form of survivorship bias. You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. People were writing sloppy PHP before CSRF and XSS were even invented. Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written. You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation where programmers can't move fast enough in adding it to their stack. Data exfiltration is no longer a flaw but a feature.
- Avamander 7y ago
  > People were writing sloppy PHP before CSRF and XSS were even invented. It is very very easy to write sloppy PHP, definitely easier than in many other languages and default frameworks. > You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. P I'm very aware of them, basically none have (had) as many high-impact vulns as PHP-based stuff does. > Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written. You're not acknowledging the orders of magnitudes difference between the impact of an usual PHP vuln and those you listed. > You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation The flaws in others are a very poor excuse for flaws in a thing itself.

biggestdecision 7y ago

PHP isn't popular because it's easy, it's popular because for a long while it was the only viable language for developing web applications.

wvenable 7y ago
Indeed. I think most developers don't understand how amazing PHP was compared to the competition and just how fast it acquired new features during those early years. It was a scripting engine with a such a thin layer of C that it could easily and quickly incorporate the huge number of open source C libraries that existed at the time.
- osrec 7y ago
  While your observation is true to some degree, I do remember ASP, Cold fusion, CGI and a few other more obscure technologies way back when. Perhaps I was quite late to the party though - I only started programming in 1999 (got a computer for my 11th birthday!) - so I'm not sure what it was like before then.
  - javagram 7y ago
    ASP and ColdFusion both required license fees at the time I believe (asp the Windows server license and CF of course the CF license) CGI just would run any type of script. Originally that was typically Perl but PHP surpassed Perl for a variety of reasons. PHP could be run either through CGI or through mod_php in Apache. There was also a mod_perl I believe and a few others but php is what web hosts typically installed in the early 2000s.
    - im3w1l 7y ago
      Why did php beat perl?
      - horizone 7y ago
        Personally, I switched from Perl to PHP around 2002 (I could be wrong with the year) as I wanted to move from flat file dbs to MySQL. I wouldn't say that it beat Perl, it was just made web development more accessible. I still wrote in Perl after that, but for server side scripting (processing, cleanup etc).

bjoli 7y ago

The same is true for python. I spent some time trying to write a CSV parser in guile scheme that was as fast as python's (mistakenly believing that python's CSV parser was actually written in python). I wrote a fast-ish streaming FSM-parser (about 100loc) but only managed to be about 1.7x as fast as python's CSV module. Browsing the python source I realised that the python parser was written in optimised and nicely buffered C. I could probably compete with python if I used guile's lower level C-procedures, but I sort of lost interest after that :)