In the early 2000s, everyone in my bubble knew that PHP was a security nightmare, only seconded by Flash. In the meantime, Adobe gave up on Flash, but PHP is still alive and rocking.
How did that happen? Did PHP get some serious makeover? Do developers just not care?
You must log in or register to comment.
Some things got better. The magic variables, the killer feature which popularized PHP and also introduced the most vulnerabilities, has been gone for more than a decade. It’s not nearly as easy to accidentally make a vulnerability now. WordPress is still horrific, though.
But the reason PHP is still around is simple: There’s not much competition.
mod_phpis still by far the most convenient way to run shared hosting. You just install the module, and people can put .php files on their website and it just works. No need to set up FastCGI, some servlet engine, reverse proxy or any of that jazz you need when using python, ruby or node.js.Sure, if you’re running your own VM somewhere, you can set all that up, but a lot of people are still on cheap, shared hosting, where all they can do is upload files via FTP. The only real scripting language which doesn’t need any server software configured is PHP, so that’s what those hosting providers support.
The only real scripting language which doesn’t need any server software configured is PHP
I mean you still need to configure the webserver to handle PHP (Apache, Nginx, or whatever). It’s not active by default.
But of course for a webhoster that’s really easy at least.
Sure, I guess I should have phrased that as “any additional server software beyond the webserver itself”, but it’s kind of a mouthful. And people would still get after me in the comments, because actually, that’s technically true for CGI as well, although the poor performance makes it a no-go for anyone doing anything commercially.
Thanks! That’s the sort of answer that I hoped for.
Have you ever seen how shared hosting works for some of the languages you mentioned? For Node for instance it’s the same as PHP, you upload an index.js and that’s it.
I may be out of date on node.js. What is the price point for that? I’d imagine they’ll have to fire up a separate interpreter for each customer? I’d expect that to be more expensive.
The point here wasn’t really the user experience, though, but what is cheap and easy to support for a company providing bottom-tier shared hosting.
It’s not more expensive. Shared hosting pick a fixed capacity and they try to cram as many customers as possible per shard. That includes shenanigans like putting two resource-intensive accounts on one shard and 50 low-resource accounts on another even though they’re all paying for the same tier.
Yes with Node you have a process per account but it’s easier and cleaner to manage resource limits like that. I will take managing shared Node hosting over PHP any day, it’s much easier and more secure.
Overall the cost of shared hosting with Node or PHP is the same, what you don’t do is offer both at once because it complicates things. Typically you let customers choose the backend language option (PHP, Python, Node) and a database engine (MySQL, Postgres, Mongo) and that’s it.
WordPress is still horrific, though.
Not wp core, or the latest core themes. Very stable, security issues are resolved pretty quickly and it’s only getting better for the past few years.
But Everything where users can contribute, plugins and themes can be garbage. Especially on the open market. Php development into WP core… still kinda nightmarerish. But modern theme development with php is a great experience. Modern themes also recommend moving the frontend templating to JavaScript.
Nearly 99% of my security audits on wp sites is looking for vulnerability from a decade ago.
So in terms of security, WP core itself has been incredibly stable.
Apropro WP: https://lemmy.world/post/6582047
Explain ‘security nightmare’? Most security issues I’ve seen were caused by stuff like passing user input directly to database queries, instead of using prepared statements. Or allowing directory traversals, again by not sanitising user input. That’s on the developer, not the language.
Stuff like register_globals and the default MySQL extension back in the bad pre-5.3 days definitely didn’t help though. But those haven’t been a problem in over a decade, so nowadays it’s on par with pretty much any other web language/framework. Especially if you use the libraries from Symfony and/or Laravel.
That’s a trip down memory lane, I once (probably a decade ago by now) had to fix a website built by an unknown developer for a customer. Was wondering why I was missing all kinds of variable assignments, until the word ‘register_globals’ floated up from the depths of my mind. And indeed, they enabled that setting in .htaccess, which broke the website after PHP 5.4 did away with it permanently. But to defend the PHP developers a bit: they turned it off by default in 4.2, which came out in 2002, because they recognised it as a security vulnerability. You can debate if that setting should have sticked around for 13 more years, but at least it required a manual action to actually be able to use it from 4.3. Although I cannot help but wonder how many shared hosting companies turned it on just to prevent all kinds of sites from breaking of course.
And yes, oh boy, the MySQL client… That one wasn’t great as it didn’t support parameterization, but I guess at least the documentation for
mysql_querywas clear that any data in your query should be escaped withmysql_real_escape_string. To be fair, if you pass unescaped data to MySQLi or PDO you are going to get Bobby Table’d just as hard.
Never used PHP, but wasn’t there a bunch of issues around the admin page being accessible?
PHP itself doesn’t have one, it does have a debug command
phpinfo()which might print sensitive information. But that’s on the programmer if they called that on a publically available page. Could also be that you meant phpMyAdmin, which is a MySQL webclient built in PHP, not an admin page for PHP itself.Yep, that’s what I was thinking of
PHP is as secure as any other language, the problem is the implementation of it.
For example I can upload a file to a webserver and the webserver is executing it instead of just reading it as text, It can be php, aspx, ruby, flask, doesn’t matter, from the point of view of the attacker the only thing that changes is which webshell he will upload.
Regarding your experience, everything was a security nightmare in the early 2000’s PHP was no exception.
For example I can upload a file to a webserver and the webserver is executing it instead of just reading it as text, It can be php, aspx, ruby, flask,
You do realize that only works for .php right? There no way to tell a Ruby or Python etc. app to run a file it wasn’t designed to run.
You are kinda right I didn’t know it was not possible on ruby (at least without chaining vulns), but it’s possible on aspx, jsp and pearl at least.
The main threat to PHP apps now are bots attempting to exploit your app to upload executables or PHP files and somehow execute them. But this is not the fault of PHP itself though, more like the app handling uploaded files in insecure manner and can happen to other apps written in other languages.
Actually, it can’t happen in other languages. It’s quite unique to PHP because it relies on a webserver to run, and that webserver will execute any file ending in .php as PHP code.
Other languages’ web engines don’t work like that. Assuming you manage to trick a Java or Node etc. into accepting a file ending in .java or .js and so on, you won’t be able to make it execute. The attempt doesn’t even make sense because those platforms don’t have a concept of allowing remote requests to indicate which file should run.
There are other backend languages that works like php in this regard such as ASP and CGI scripts (Perl, etc). Basically, if you have a bug that can be exploited to replace the app source code or binary, your backend will have similar vulnerability unless your backend uses a strict process control system (only loads source code / binary files on backend start and ignore subsequent file updates), which is the default for many backend languages these days but not all of them.
PHP makes up like 80% of all websites worldwide.
I must is missed the security concerns, I didn’t start programming in PHP until 2003.
PHP makes up like 80% of all websites worldwide.
That statistic is ridiculous and I wish people would stop quoting it because it’s not doing anybody any favors. In particular it completely discredits PHP from any chance of claiming some reasonable numbers.
The survey’s methodology is full of holes and biases and completely fails to account for all kinds of factors, such as the fact that most websites out there don’t have “powered by” headers (it’s not a thing for most of the languages they claim to have detected; and how do you detect “static files”?), or that modern cloud infrastructure is distributed and cannot be evaluated like the monolithic on-premise servers of decades ago.
If you’re still not convinced I give you two things to consider:
- Take a large site that you know for a fact is powered by PHP, like wordpress.com or any of the blogs hosted by them, and look at the HTTP headers. They don’t say anything about PHP.
- Look at the rest of the survey results. They say Ruby is more widely used than Java and Node. That Scala is more widely used than Python. That Coldfusion and Erlang are in the top ten of web server technologies. None of it makes any sense.
