this post was submitted on 10 Oct 2023
70 points (88.9% liked)

Technology

59374 readers
3671 users here now

This is a most excellent place for technology news and articles.

Our Rules

  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
70
How is the security level of PHP in 2023? (lemm.ee)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
23 comments fedilink hide all child comments
 

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?

top 23 comments
sorted by: hot top controversial new old
[–] [email protected] 48 points 1 year ago (4 children)

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_php is 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.

[–] [email protected] 15 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 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.

[–] [email protected] 6 points 1 year ago

Thanks! That's the sort of answer that I hoped for.

[–] [email protected] 5 points 1 year ago (1 children)

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.

[–] [email protected] 4 points 1 year ago (1 children)

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.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

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.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 26 points 1 year ago (2 children)

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.

[–] [email protected] 13 points 1 year ago (1 children)

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.

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago)

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 driver.. 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 execute a query containing unescaped data with MySQLi or PDO directly you are going to get Bobby Table'd just as hard.

[–] [email protected] 0 points 1 year ago (1 children)

Never used PHP, but wasn’t there a bunch of issues around the admin page being accessible?

[–] [email protected] 2 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago

Yep, that’s what I was thinking of

[–] [email protected] 23 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 0 points 1 year ago (1 children)

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.

[–] [email protected] 2 points 1 year ago

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.

[–] [email protected] 9 points 1 year ago (1 children)

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.

[–] [email protected] -3 points 1 year ago (1 children)

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.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

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.

[–] [email protected] 8 points 1 year ago (1 children)

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.

[–] [email protected] 11 points 1 year ago* (last edited 1 year ago)

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:

  1. 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.
  2. 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.