5 ms·

> While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can

by sbarre 10y ago

> While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious <script> tags and PHP placing it happily into generated HTML (eg. XSS attacks). > PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks. You can make these beginner mistakes in any language that outputs HTML to the browser, and accepts user input via the browser. I'm not specifically defending PHP here, but I hope you're not implying that these problems don't exist in Ruby, Python, Java or even Node for that matter... The issues you are describing are unsafe coding practices and have nothing specifically to do with how PHP works, and it's "trivially easy" to make those mistakes in almost all web programming languages. It's also not true that PHP "can't escape the strings it injects into HTML". There are standard library functions to do this (and have been for probably 10+ years, since the late PHP 4 days), as well as many well-tested community packages to do this at the framework or application level. Also your explanation of "plugins" and "themes" is a concept tied to applications such as Wordpress, Joomla, and other CMS products (and again are not concepts specific to PHP). It's certainly true that PHP's low barrier to entry has led to many badly coded websites getting onto the Internet, but I think it's ignorant to claim that PHP can't be used correctly and safely to develop web applications, or that most of the problems you describe are not easily avoidable. All languages and frameworks have their pros and cons, and their caveats, but it helps no one when people spread FUD and outdated (or straight-up false) facts about web development. Whether you code in it or not, you should probably refresh your knowledge of the PHP language and ecosystem if you're going to make public statements about how it works and what it can and can't do.

tannhaeuser 10y ago
Reading through it, my comment came about too much as a rant against PHP, though I actually like parts of the PHP community for their sense of practicality. I know there are libraries for HTML escaping, but I stand behind my statement that PHP's lack of HTML escaping is a fatal and unforgivable (almost criminal) design flaw when PHP's original use case, and distinguished feature vs. other general-purpose languages is dynamic HTML templating. In my opinion, PHP has gone the "get something quick out there and fix it later to become the dominant web runtime" route (which kind of worked), but without doing the actual hard work, and as such deserves to be called out.
- sbarre 10y ago
  You're calling out problems that are common to all programming languages on the web, and I think you're just focused on PHP because it was one of the first languages to run into those problems (and to solve them as well - HTML escaping functions are part of PHP's core, it's not a library) due to it's early widespread popularity and adoption. Trailblazers often bear the brunt of learning through trial and error, and later adopters benefit from all those lessons learned. This includes the PHP language and ecosystem of today, that looks nothing like what you describe. Also: show me a popular web programming language that prevents the problems you called out (at the language level, not the framework level). You can output unescaped input, or create SQL injections, in any language if you don't know what you're doing, or if you're using the wrong tools. Again if you want to keep speaking on the topic, I encourage you to refresh your knowledge on the PHP programming language (and probably also on web development in general if you think other languages don't also have the same pitfalls). Your concerns and opinions are literally 10+ years out of date.
  - bpicolo 10y ago
    > show me a popular web programming language that prevents the problems you called out (at the language level, not the framework level). Golang? https://golang.org/pkg/text/template/ https://golang.org/pkg/text/template/
- ssharp 10y ago
  PHP made it way too simple to go from a basic installation -> serving web pages, just using it's standard library. You're right -- that was it's intended use-case and while it made for a dead-easy user experience, it also planted lots of traps that users fell into in droves. Where languages like Ruby had Rails and Python had Django, PHP was able to do things quickly without having a framework on top of it. That, coupled with clear design flaws and a standard library that lacked, well, standardization, made it an easy and deserving target for criticism. PHP was also slow to adopt objects, namespaces, package management and other things developers came to expect.
  - t0mislav 10y ago
marcosdumay 10y ago
It's not what you can do, it's how hard it is. Just try pulling data from a database and inserting it into a page on a way that is vulnerable to XSS in Django, Jinja, or Rails. You obviously can do it, but I bet you'll need to spend half an hour reading the documentation before you succeed. The same happens for SQL injection, and session management issues, and a huge amount of other problems.
- tpetry 10y ago
  The fault in your argumentation is comparing a language (PHP) to a framework (Django, Jinja, Rails). Your argument is valid too for any PHP framework, it's hard to do XSS in laravel, symfony or zend framework.
  - Joeboy 10y ago
    PHP is a web framework. It's just one that requires another framework on top to mitigate its shortcomings.
    - Prefinem 10y ago
      I use PHP quite a bit outside of the web. I think tpetry was pointing out the difference between a language and a framework built on that language. (Replace language with whatever you think it is, it's still a subset just like Ruby on Rails is a subset of Ruby)
      - Joeboy 10y ago
        And I'm pointing out that treating PHP as a framework is not a "flaw in argumentation". The default installation of PHP gives you a setup that parses HTTP requests and returns HTTP responses, and provides a bunch of web-centric functionality in between. ie. it's a web framework, albeit not a very good one.
        Prefinem 10y ago
        > The default installation of PHP gives you a setup that parses HTTP requests and returns HTTP responses Correct me if I am wrong, but so does Node, Ruby, Python, etc... Sure it was built for the web, in simpler times, but everything has to start somewhere. Now days, PHP is a completely different beast. > Just not a very good one. An opinion if fine, but it seems like you are deriving this opinion from old experiences (or maybe the old PHP hate bandwagon)
jeltz 10y ago
Of course you can write safe code in PHP, it is a complete general purpose programming language. But just like one can blame C's design and standard library for many security bugs I also think it is fair to blame PHP's standard library and design. For example PHP's PDO library makes it less convenient to supply parameters to a query the safe way than it is to do it the unsafe way. This is not necessary as can be seen from the excellent Ruby library called Sequel where it is just as easy to do things the safe way. Another example is PHP itself being a template language, but which lack of automatic escaping makes it very dangerous to use. Since just one missing escape call in the wrong place can fuck up your day. To be fair PHP is not the only one who has fucked up here. This is also an issue with Ruby's ERB templates in the standard library, but fortunately Rails has added automatic escaping to its ERB templates. One important thing about designing safe software is to make it easy for the end users to do things the right way, and here I think PHP has done a pretty poor job.
- Prefinem 10y ago
  I would say it's unfair to compare a library to the basic PDO. If you want to compare apples to apples, try looking at Sequel versus Doctrine or some other third party SQL library. Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache. But you don't have to use it that way, and probably shouldn't. While PHP started as a template language, it has clearly moved past that.
  - jeltz 10y ago
    I do not think it is an unfair comparison since Sequel has both basic parts on the same level as PDO, and then implements the more advanced features on top of these basic parts. The basic parts of Sequel has superior usability and safety to PDO. Sequel's right way: user = db['SELECT name FROM users WHERE id = ?', id].first Sequel's wrong way: user = db["SELECT name FROM users WHERE id = #{id}"].first PDO's right way: $stmt = $db->prepare('SELECT name FROM users WHERE id = ?'); $stmt->execute([$id]); $user = $stmt->fecth(); PDO's wrong way: $user = $db->query("SELECT name FROM users WHERE id = $id")->fetch(); As you can see PDO is optimized for doing things easily the unsafe way while Sequel has the safe way as the normal way of running queries which is just as easy to use as the unsafe way. > Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache. That is simply not true. Look at Twig which by default escapes everything automatically, or Rails's patched ERB which keeps track of escaped an unescaped strings based on data types and makes sure everything is automatically escaped in the end. In those template languages you need the explicitly do something unsafe to get an unescaped value. While in PHP you need to audit all places where echo can be called directly or indirectly.

by sbarre 10y ago

tannhaeuser 10y ago

Reading through it, my comment came about too much as a rant against PHP, though I actually like parts of the PHP community for their sense of practicality. I know there are libraries for HTML escaping, but I stand behind my statement that PHP's lack of HTML escaping is a fatal and unforgivable (almost criminal) design flaw when PHP's original use case, and distinguished feature vs. other general-purpose languages is dynamic HTML templating. In my opinion, PHP has gone the "get something quick out there and fix it later to become the dominant web runtime" route (which kind of worked), but without doing the actual hard work, and as such deserves to be called out.

sbarre 10y ago
You're calling out problems that are common to all programming languages on the web, and I think you're just focused on PHP because it was one of the first languages to run into those problems (and to solve them as well - HTML escaping functions are part of PHP's core, it's not a library) due to it's early widespread popularity and adoption. Trailblazers often bear the brunt of learning through trial and error, and later adopters benefit from all those lessons learned. This includes the PHP language and ecosystem of today, that looks nothing like what you describe. Also: show me a popular web programming language that prevents the problems you called out (at the language level, not the framework level). You can output unescaped input, or create SQL injections, in any language if you don't know what you're doing, or if you're using the wrong tools. Again if you want to keep speaking on the topic, I encourage you to refresh your knowledge on the PHP programming language (and probably also on web development in general if you think other languages don't also have the same pitfalls). Your concerns and opinions are literally 10+ years out of date.
- bpicolo 10y ago
  > show me a popular web programming language that prevents the problems you called out (at the language level, not the framework level). Golang? https://golang.org/pkg/text/template/ https://golang.org/pkg/text/template/
ssharp 10y ago
PHP made it way too simple to go from a basic installation -> serving web pages, just using it's standard library. You're right -- that was it's intended use-case and while it made for a dead-easy user experience, it also planted lots of traps that users fell into in droves. Where languages like Ruby had Rails and Python had Django, PHP was able to do things quickly without having a framework on top of it. That, coupled with clear design flaws and a standard library that lacked, well, standardization, made it an easy and deserving target for criticism. PHP was also slow to adopt objects, namespaces, package management and other things developers came to expect.
- t0mislav 10y ago

marcosdumay 10y ago

It's not what you can do, it's how hard it is. Just try pulling data from a database and inserting it into a page on a way that is vulnerable to XSS in Django, Jinja, or Rails. You obviously can do it, but I bet you'll need to spend half an hour reading the documentation before you succeed. The same happens for SQL injection, and session management issues, and a huge amount of other problems.

tpetry 10y ago
The fault in your argumentation is comparing a language (PHP) to a framework (Django, Jinja, Rails). Your argument is valid too for any PHP framework, it's hard to do XSS in laravel, symfony or zend framework.
- Joeboy 10y ago
  PHP is a web framework. It's just one that requires another framework on top to mitigate its shortcomings.
  - Prefinem 10y ago
    I use PHP quite a bit outside of the web. I think tpetry was pointing out the difference between a language and a framework built on that language. (Replace language with whatever you think it is, it's still a subset just like Ruby on Rails is a subset of Ruby)
    - Joeboy 10y ago
      And I'm pointing out that treating PHP as a framework is not a "flaw in argumentation". The default installation of PHP gives you a setup that parses HTTP requests and returns HTTP responses, and provides a bunch of web-centric functionality in between. ie. it's a web framework, albeit not a very good one.
      - Prefinem 10y ago
        > The default installation of PHP gives you a setup that parses HTTP requests and returns HTTP responses Correct me if I am wrong, but so does Node, Ruby, Python, etc... Sure it was built for the web, in simpler times, but everything has to start somewhere. Now days, PHP is a completely different beast. > Just not a very good one. An opinion if fine, but it seems like you are deriving this opinion from old experiences (or maybe the old PHP hate bandwagon)

jeltz 10y ago

Of course you can write safe code in PHP, it is a complete general purpose programming language. But just like one can blame C's design and standard library for many security bugs I also think it is fair to blame PHP's standard library and design. For example PHP's PDO library makes it less convenient to supply parameters to a query the safe way than it is to do it the unsafe way. This is not necessary as can be seen from the excellent Ruby library called Sequel where it is just as easy to do things the safe way. Another example is PHP itself being a template language, but which lack of automatic escaping makes it very dangerous to use. Since just one missing escape call in the wrong place can fuck up your day. To be fair PHP is not the only one who has fucked up here. This is also an issue with Ruby's ERB templates in the standard library, but fortunately Rails has added automatic escaping to its ERB templates. One important thing about designing safe software is to make it easy for the end users to do things the right way, and here I think PHP has done a pretty poor job.

Prefinem 10y ago
I would say it's unfair to compare a library to the basic PDO. If you want to compare apples to apples, try looking at Sequel versus Doctrine or some other third party SQL library. Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache. But you don't have to use it that way, and probably shouldn't. While PHP started as a template language, it has clearly moved past that.
- jeltz 10y ago
  I do not think it is an unfair comparison since Sequel has both basic parts on the same level as PDO, and then implements the more advanced features on top of these basic parts. The basic parts of Sequel has superior usability and safety to PDO. Sequel's right way: user = db['SELECT name FROM users WHERE id = ?', id].first Sequel's wrong way: user = db["SELECT name FROM users WHERE id = #{id}"].first PDO's right way: $stmt = $db->prepare('SELECT name FROM users WHERE id = ?'); $stmt->execute([$id]); $user = $stmt->fecth(); PDO's wrong way: $user = $db->query("SELECT name FROM users WHERE id = $id")->fetch(); As you can see PDO is optimized for doing things easily the unsafe way while Sequel has the safe way as the normal way of running queries which is just as easy to use as the unsafe way. > Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache. That is simply not true. Look at Twig which by default escapes everything automatically, or Rails's patched ERB which keeps track of escaped an unescaped strings based on data types and makes sure everything is automatically escaped in the end. In those template languages you need the explicitly do something unsafe to get an unescaped value. While in PHP you need to audit all places where echo can be called directly or indirectly.