Joomla SQL-Injection Flaw Affects Millions of Websites (trustwave.com) 120
An anonymous reader writes: Joomla has just issued a patch that fixes a SQL-injection vulnerability discovered by a researcher at Trustwave SpiderLabs. The flaw allowed malicious users to extract a browser cookie assigned to a site's administrator, giving them access to restricted parts of the server. The flaw first appeared in Joomla 3.2, released in November, 2013. An estimated 2.8 million websites rely on Joomla. The Joomla team and the researcher who found the flaw recommend an immediate update to version 3.4.5.
Re: (Score:1)
If you want a proper setup it should be nodejs with a websocket handling data flow
A websocket to whom, the client? The client surely is not a javascript-enabled browser, since everyone with a brain in their heads disables that shit on day one.
PHP is unable to broadcast data between clients or to specific clients from another client
??????????????
Do you actually have any idea what you're talking about? This sounds completely out of touch with the web.
Re: (Score:1)
client side:
$('sendButton').on('click',function(){ socket.emit('send message',msg,Dale) });
server side:
socket.on('send message',function(msg,targetUser){
for(var i in sockets){
if(socket.thisuser==targetUser){socket.emit('sent msg',msg);}
}
});
This is all javascript, all of which will not execute because most users do not have such a thing enabled in their browsers. Did you even read my post before you started shooting raw liquid feces all over your screen?
Re: (Score:2)
"...most users do not have such a thing enabled in their browsers."
[[Citation Needed]]
Seriously, back that shit up. You made the claim, show me some evidence. A quick Google (sorry, not my job to prove you right) says that you're full of shit and trying to weasel your way out of being incorrect by telling straight up lies. Pretty much every site that attempts to quantify this seems to indicate you're completely retarded. Try 2-4% of web users browse with JS disabled.
Re: (Score:2)
Oh wow! If only you could somehow filter out injection attacks!
I know...if only there was a way. But we all know it's totally impossible to do, so we might as well get used to it.
Re: (Score:3)
You do know the reasons why PHP CMSes like Wordpress are ridiculously popular is that it is dead easy to find a host that already runs PHP and MySQL right? Most of those installs aren't owned by developers. They're owns by regular people.
Re: (Score:1)
Not to mention that WordPress is by now probably the most widely-deployed self-updating system short of windows.
Serious security vulnerabilities in core like this (which with WP are now very rare indeed, because WP core developers are competent and serious) get fixed on most users' machines within hours of the fix being published.
There are many, many problems with plugins and themes still, but for the most part these issues would exist with any system architected and developed with community code; WP develo
Re: (Score:1)
Using a datastore with ZERO recovery logic (innodb) wasn't your first mistake?
Re: (Score:1)
Fine, but in the real world, more often than not you inherit large SQL databases, and programs that are written to use these databases.
Now, are you telling me that you'd want to undo an entire company's database structure over a problem that can be prevented with proper filtering? Note that you're not getting paid any extra to do this, hardly anyone is going to appreciate your effort, and if ANYTHING goes wrong it's YOUR fault.
If you get a chance to build something from scratch, I'm all for a current setup
Re: I don't get it... (Score:1)
You most likely don't have the same user base as joints or Wordpress. I'm sure someone would find holes in your code givin enough attention.
Today I Learned (Score:2, Funny)
Today I learned that I write more secure code than all of the fucking coders at Joomla put together.
A decent sized company with loads of resources, lots of code reviews, using Agile, Scrum, Waterfall, SuckMyPecker, and (supposedly) staffed with experienced programmers, and they STILL fuck it up.
Re: (Score:3, Informative)
Joomla is not a company. The people developing it are volunteers.
Re: (Score:3)
Well said. And it only takes one mistake by one person to introduce a vulnerability. In hundreds of thousands of lines of code.
Just switch to Plone (Score:1)
Just switch to Plone and sleep easier at night. A little out of date figures, but in the time Joomla had 441 exploits, Plone had 9.
https://plone.org/products/plo... [plone.org]
-Matt
Re: (Score:2)
Has it improved much since 2006? When I used it back then it was awful. Slow, terrible UI, over engineered.
Re: Just switch to Plone (Score:1)
Has it changed in 9 years? Yes of course. Several major versions since then. There is a new content-type system, new theming system, and new UI.
Check out the recently released Plone 5 which has lots of great stuff in it.
https://plone.com/5 [plone.com]
-Matt
Re: (Score:1)
Indeed. Hackers tend to target more popular tools over the less popular. It doesn't even seem to be linear such that a tool that's twice as popular gets hacked roughly 4 times as much. That's because they want the biggest bang (most "customers") for their buck.
Ugh, need a clue-bat for commenters (Score:2)
What's with all the anonymous wankers beaking off about PHP vs Node, or JavaScript in general, when it's a server-side parsing of input that leads to the vulnerability? WebGoat was written as an on-purpose vulnerable web app for learning on, maybe some of you should download it and Burp or ZAP and do some self-education. OTOH, I'm sure someone would look at WebGoat, and respond with, "OMG, Java is teh suckz!"
Re: (Score:2)
Whoops, that was me. One side effect of auto-clearing cookies. Anyway.
Re: (Score:2)
These appear to be the types of people who have just a hammer in their toolbox and insist they're able to fix anything with it. They could at least get some duct tape.
If it moves, and it shouldn't, duct tape. If it doesn't move, and it should, hammer. They'd at least broaden their horizons. Me? I can code poorly in a whole bunch of languages.
so, does this only work ... (Score:2)
So, does this only work if errors are output to the screen?
Trying to assess the impact to our client sites. We always write errors to file and not to screen.
No surprise... (Score:2)
Re: (Score:1)
Wordpress has had plenty of vulnerabilities also. You just got to patch quickly when vulnerabilities are found.
Re: (Score:2)
Re: (Score:1)
Do you know any good static-based systems?
Re: (Score:1)
Ruby? Our shop would rather go with a Php-based one.
Re: (Score:2)
Woaw, you clearly know what you are talking about. Good arguments too. You must be some Code Writing Guru.
Anyway, just wanted to let you know that all my PHP based websites are running fine for many, many years. Without patching that is. And yes, they've seen a lot of hack attempts. None was successful.
Bye,
A self-trained PHP monkey
Re: (Score:2)
just wanted to let you know that all my PHP based websites are running fine for many, many years. Without patching that is. And yes, they've seen a lot of hack attempts. None was successful.
Same here...like you, I'm a "self-trained PHP monkey".
I run dozens of sites, some going back ~12 years or so. Hackers throw themselves against my sites constantly and none of them have managed to get in or run a successful exploit. Careful coding and rigorous sanitizing of incoming data is really all it takes.
Cheers!
Re: (Score:2)
As opposed to all the other-trained monkeys that use whatever wunderscript language their professors adored?
Re: php frameworks (Score:4, Informative)
But objectively speaking, bad coders write bad code no matter what kind of database or programming language you give them. They mess up
Re: (Score:2)
Re: (Score:1)
Schlitzpunkt
I think you mean Solidusfullstop.
Re: (Score:2)
This folks is why, just the other day, I decided to create my magnum opus. I will write, and give away, a CMS - free for the taking, truly libre in every sense of the word. I'm going to do it in uncommented Perl with as few lines as possible.
I expect to be a few months brushing up my skills but, damn it, it's going to be flat text file databases - everywhere. Imma store plain text passwords in plain text files. And I'm going to give it away.
You may think I'm kidding. I'm not. I just really, really, don't li
Re: (Score:2)
Re: (Score:2)
any side JS is not much better.
Re: (Score:2, Insightful)
Preventing SQL injection attacks is trivially easy with very modest understanding of what you're doing.
Suggesting that they ditch one technology for another as a cure-all makes you part of the problem. Rather than try and understand what is going on, you'd rather have a language and/or framework handed to you that promises to solve everything. It is this mindset that results in pants-on-head stupid bugs to reach production.
Re: (Score:2)
Lol, I just love sweeping statements like this, made under "Anonymous Coward", of course.
Re: (Score:2)
Re: (Score:3)
PHP has nothing to do with it. PHP is just as secure / insecure as any other language. It's the fact that PHP is easy to learn, easy to use and easy to deploy that attracts many people, including noobs. It's the noobs that cause the problems.
To prove that PHP can be used to create a rock solid and secure website, take a look at the Banshee PHP Content Management Framework [banshee-php.org]. I dare you to try it. You will be suprised by its security, flexibility, easiness and speed.
Re: (Score:2)
The bet is on! Bring it on. I double dare you!! And if you're as tough as you sound, in time you will admit you are wrong.
Re: php frameworks (Score:1)
Rails is not inherently secure, and insecure Rails apps have definitely been written. Early on, though they professed their expertise, they had to be schooled on the difference between GET and POST and why one should never use GET if the action was not idempotent.
Security can be a function of a language but it doesn't end with the language. Rails has no inherent security, just libraries built with good practice.
Re: (Score:1)
Your true colors are showing now. You must realize, as soon as you mention RoR, any real programmer will fall over laughing at you. Nice try kiddo, pretty good troll.
Re: (Score:2)
Take a look at the security_audit script. Run it and it will tell you what needs your attention with respect to SQL injection and cross-site scripting.
XSLT prevents XSS, because every output will be escaped by default. Printing output as it is (printing HTML tags unescaped) requires adding the XML parameter 'disable-output-escaping="yes"'. By doing so, you are clearly warned. Fuck it up and it is clearly your own stupid mistake.
SQL injection is prevented the same way. The SQL library won't accept queries wi