Submitted 1 year ago by redballooon@lemm.ee to technology@lemmy.world
I’m not a web developer, even though various managers sometimes try to make me one. So sometimes I peeked…
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?
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_query was clear that any data in your query should be escaped with mysql_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.
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.
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.
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 or 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:
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).
bus_factor@lemmy.world 1 year ago
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.
Vlyn@lemmy.zip 1 year ago
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.
bus_factor@lemmy.world 1 year ago
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.
lemmyvore@feddit.nl 1 year ago
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.
bus_factor@lemmy.world 1 year ago
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.
redballooon@lemm.ee 1 year ago
Thanks! That’s the sort of answer that I hoped for.
Potatos_are_not_friends@lemmy.world 1 year ago
Not wp core, or the latest core themes.
Everything where users can contribute, plugins and themes can be garbage. Especially on the open market. But as for php development of core… well 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.
In terms of security, WP core itself has been incredibly stable.
StreetKid@reddthat.com 1 year ago
Apropro WP: lemmy.world/post/6582047