I'm literally not surprised by anything in this article. Joomla is a mess (my opinion, doesn't actually matter to my point), written in PHP so whenever a patch is released, you can see exactly what the exploit was. In fact, I'm surprised it's not less than 2 hours.
So obviously, "Patch now!" - although, that's not the prerogative of this site, it's to convince you to purchase their "website antivirus" -- which I still can't work out what it actually does, or where it sits.
I can't tell for sure either. Their pages about it, as usual, are heavy on marketing and light on technical details. In one case it looks like they offer a CloudFlare-like service (http://cloudproxy.sucuri.net/features), and then in another case, they offer it as a Wordpress plugin (https://wordpress.org/plugins/sucuri-cloudproxy-waf/faq/) (and presumably for other platforms too).
Given modern web development trends though, I'm sure they'll be very successful at selling their product without bothering with things like technical details.
But it is such a simple CMS. I can make user groups and assign each group to a section or download section using DocMan. I can revoke rights to one use or the whole group. I cannot do this in Wordpress.
That kind of authentication and authorization can be found in any respectable CMS. Choosing Joomla because Wordpress isn't any better is like choosing to drink your own urine for breakfast because stools taste worse.
Joomla, from the age of the monolithic frameworks, easy to take down and infiltrate because it is monolithic molasses. I feel for the souls trapped in the joomla monolith sludge.
Ah, the tainted legacy of PHP applications originally built in the early 2000's. I doubt anything has been responsible for more exploits than the lack of the ability to do parameter binding in PHP's original MySQL driver.
The driver isn't totally to blame, too many developers weren't and still aren't trained properly.
The problem is actually that users would probably never have used parameter binding even if it was available. Despite the original mysql driver not supporting parameter binding you could still mitigate against SQL injection attacks even back then. The mysql_real_escape_string() function is available to help prevent SQL injection attacks, it's been around since the dawn of PHP4 (yes I know it's not totally secure if you're not aware of your character encoding [0]) . But barely anyone used it, or even understood the purpose of mysql_real_escape_string().
I've had to trawl through ancient customer code which uses the old mysql driver on our hosting platform to explain why their site got hijacked. There's more often that not even a single use of mysql_real_escape_string(). This is code written by pro-developers I'm often told. There's not even attempts to perform naive quote escaping.
The real issue is education. There are still hoards of developers who have never heard of SQL injection. Part of the problem was that the PHP documentation from back in the day provided poor examples, the other part sites like W3S omitting any mention of mitigating against SQL injection attacks. So folks merrily copy/paste never even having heard of the concept of SQL injection.
I still have to educate customers about SQL injection attacks and many still stick their heads in the sand and don't want to believe this could possibly happen, or blame us.
And for all of the PHP team's prognostications about binning the mysql driver, folks will just move on to mysqli or PDO and still carry on doing stuff like:
$sql = "SELECT name FROM people WHERE name='$name'";
This isn't a problem specific to PHP, it's still endemic in codebases written in Classic ASP, ASP.NET, Java, python all churned out by herds of badly trained developers blissfully ignorant of the mess they're creating for their clients.
Yes, but mysql_real_escape_string is a horrible, inefficient solution to a well understood problem with well understood industry standard solutions. Bound parameters were introduced into Perl's DBI module in August of 1995[1] and in the DBD::mysql module in 1997, and those reference DBD::Oracle when noting where you can get more info, so they weren't the first.
My main problem with PHP on this subject is that their response to this problem for years was so lackluster, when it wasn't non-existent, that I can't give tutorials all the blame. The entire ecosystem was initially built on terrible, insecure practices for negligible benefit (I'm looking at you, register_globals), and it cost everyone on the web, not just PHP developers, for many years. And it's not like they didn't have multiple chances to fix major problems. Conversions from PHP 3 to PHP 4 were happening back in 2001. The mysql extension survived that. It also survived the migration from PHP 4 to PHP 5 in 2004. They fixed register_globals back in the PHP 4 release in 2001, but it took until 5.5, released in June of 2013 to deprecate the mysql driver.
As a hoster I can say that WordPress is pretty good provided you keep up to date. Security problems such as SQL injection attacks usually arise from badly written third party plugins that don't and won't take advantage of core data access API's, and instead write their own crap.
I really enjoy Joomla because of the 3RD party module, such as Docman, for my clients. My sites run just so users can login, go to the download section which is running Docman. I can assign users in groups to certain downloads.
When I work on a Joomla site I disable the Administrator.php page and make a .htaccess line that will redirect anyone attempting to access that page. So far I've never had one SQL injection/base64 exploits (I think thats what it is called). As long as I keep it updated I should be fine.
20 comments
[ 4.7 ms ] story [ 63.9 ms ] threadSo obviously, "Patch now!" - although, that's not the prerogative of this site, it's to convince you to purchase their "website antivirus" -- which I still can't work out what it actually does, or where it sits.
Given modern web development trends though, I'm sure they'll be very successful at selling their product without bothering with things like technical details.
I'm glad I don't have to maintain anything in it again.
https://www.trustwave.com/Resources/SpiderLabs-Blog/Joomla-S...
I wouldn't touch that software with a 10-foot pole.
The problem is actually that users would probably never have used parameter binding even if it was available. Despite the original mysql driver not supporting parameter binding you could still mitigate against SQL injection attacks even back then. The mysql_real_escape_string() function is available to help prevent SQL injection attacks, it's been around since the dawn of PHP4 (yes I know it's not totally secure if you're not aware of your character encoding [0]) . But barely anyone used it, or even understood the purpose of mysql_real_escape_string().
I've had to trawl through ancient customer code which uses the old mysql driver on our hosting platform to explain why their site got hijacked. There's more often that not even a single use of mysql_real_escape_string(). This is code written by pro-developers I'm often told. There's not even attempts to perform naive quote escaping.
The real issue is education. There are still hoards of developers who have never heard of SQL injection. Part of the problem was that the PHP documentation from back in the day provided poor examples, the other part sites like W3S omitting any mention of mitigating against SQL injection attacks. So folks merrily copy/paste never even having heard of the concept of SQL injection.
I still have to educate customers about SQL injection attacks and many still stick their heads in the sand and don't want to believe this could possibly happen, or blame us.
And for all of the PHP team's prognostications about binning the mysql driver, folks will just move on to mysqli or PDO and still carry on doing stuff like:
This isn't a problem specific to PHP, it's still endemic in codebases written in Classic ASP, ASP.NET, Java, python all churned out by herds of badly trained developers blissfully ignorant of the mess they're creating for their clients.[0]: http://stackoverflow.com/a/12118602/419
My main problem with PHP on this subject is that their response to this problem for years was so lackluster, when it wasn't non-existent, that I can't give tutorials all the blame. The entire ecosystem was initially built on terrible, insecure practices for negligible benefit (I'm looking at you, register_globals), and it cost everyone on the web, not just PHP developers, for many years. And it's not like they didn't have multiple chances to fix major problems. Conversions from PHP 3 to PHP 4 were happening back in 2001. The mysql extension survived that. It also survived the migration from PHP 4 to PHP 5 in 2004. They fixed register_globals back in the PHP 4 release in 2001, but it took until 5.5, released in June of 2013 to deprecate the mysql driver.
1: http://search.cpan.org/~timb/DBI-1.634/Changes#Changes_in_DB...
When I work on a Joomla site I disable the Administrator.php page and make a .htaccess line that will redirect anyone attempting to access that page. So far I've never had one SQL injection/base64 exploits (I think thats what it is called). As long as I keep it updated I should be fine.