Never used PHP, but wasn’t there a bunch of issues around the admin page being accessible?
Comment on How is the security level of PHP in 2023?
Aganim@lemmy.world 11 months ago
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.
AA5B@lemmy.world 11 months ago
Aganim@lemmy.world 11 months ago
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.AA5B@lemmy.world 11 months ago
Yep, that’s what I was thinking of
jonne@infosec.pub 11 months ago
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.
Aganim@lemmy.world 11 months 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 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.