Slashdot Mirror
Joomla SQL-Injection Flaw Affects Millions of Websites (trustwave.com)
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.
Hey Apple fanboi. I'm hardly a fan of PHP but if you think node is the solution to all hacks you're in serious need of an education.
Hello, php and sql are both very old technologies, and generally unsatisfactory for security and function reasons. PHP is unable to broadcast data between clients or to specific clients from another client. Sql fusing operation and data into one string is madness in modern setups.
If you want a proper setup it should be nodejs with a websocket handling data flow and an object database like nedb or mongo db.
Object oriented databases are immune to string based attacks because their function and data are seperated. //This can be broken by injecting data that isn't supposed to be there into the string //for instance it could be changed to 'SELECT user FROM table_name WHERE userID=1 AND 1=1' //the 1=1 makes the statment true, and all users are returned //The parameters of the find are {}, but the operation find is outside of this area, making injection or altering the operation taking place impossible.
ex SQL:
$qeury= 'SELECT user FROM table_name WHERE userID=1';
vs
ex NEDB:
database.find({},function(error,results){
});
Lol! Nothing leads to exploits like an untyped language.
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.
educate me as to how an object database is easier to compromise than an sql.
Because as far as I can see, you are speaking from your derriere sir
What is going on is that when the language was created they didn't think of this scenario hard enough and it's architecture allows injection.
I think a proper cure all would be to drop the old vulnerable language and use one which is not vulnerable. I am apparently an alien for having such logic. strange.
It's not easier.
But objectively speaking, bad coders write bad code no matter what kind of database or programming language you give them. They mess up
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
nice, encoding fail. There is a trade-mark character at the end of that post.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
So even though I came up with the correct solution, you did not, and you have no idea how an object database would be compromised your still trying to stand by your point instead of just saying 'yes, you are correct i should be using better technology to do a better job'
and your implying I am a poor coder? I believe the opposite is true.
I can grow and change with new code, ideas, and methods, your stuck in what you know and don't want to ever leave even if it doesn't work very well.
do you commit code to production as thoughtlessly as you skip over the 'preview' when answering comments on Schlitzpunkt?
Means three days ago. Neat
Lol, I just love sweeping statements like this, made under "Anonymous Coward", of course.
Just cruising through this digital world at 33 1/3 rpm...
.... big open source projects with lots of developers and they STILL have SQL injection attacks?
Call me lucky as hell, but I've yet to run into ONE SQL injection attack on anything I've written. Is ti really that difficult for people to write quality, secure code? =\
If you can't upgrade at this moment, consider disabling the website immediately. You've got a nice shell to the hosting server, and depending on how ancient that is you're a privilege escalation exploit away from damnation.
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.
Just cruising through this digital world at 33 1/3 rpm...
Schlitzpunkt
I think you mean Solidusfullstop.
The 'kill it with fire' approach my be appropriate for a personal website or a small corporate 'brochureware' site, but in the real world people need to support production code without rebuilding it based on whims of the latest 'architect'. However, those that would put in place new 'PHP solutions' should be hunted for sport.
Lol! Is your first name "Tard"?
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...
-Matt
I don't trust CMSes and frameworks over my own ability to code.
Watch out, maybe his last name is "is".
... because shallow bugs are always found so quickly.
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!"
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. I dare you to try it. You will be suprised by its security, flexibility, easiness and speed.
It doesn't have to be like this. All we need to do is make sure we keep talking.
I struggle to believe this, because your grasp of grammar and punctuation is poor. I have met many competent people who write like you, and I am not suggesting you aren't highly intelligent, but what I will say is, I've never met a great developer who writes like you. (I'm going to guess that english is your first language, too, because most non-native-speaking developers I have encountered can write better than this.)
Typing style has nothing to do with SQL injection, since it's how the query is passed to the parser. PHP also has ways of checking type, but you shouldn't use them to write queries--use the mechanism supplied by the database instead.
Except in PHP even good coders are prone to bad practices. Because PHP is not a programming language, it's a disease. I am a professional senior software engineer with 25+ years of experience and I am not touching anything that has PHP on it, inside it, near it or is however related to it. In fact I am aggressively declining work offers that involve PHP (so as not to be contacted again). It is like being asked to work with cancer cells without proper protection gear. Any professional with a bit of pride will do the same. Eventually we will rid the planet of anything PHP, including Facebook.
I applaude the thought and intention. Just a correction though, PHP is not a language. Even the thing's creator says so. Let's stop calling it what it is not and instead call it for what it is: the web's disease. In fact we should have it legally banned, and put people who use it in jail for good for they are a threat to humanity.
Blah blah blah. I've been writing software for over 30 years. Yes PHP is garbage just as JavaScript is garbage. SQL is not the issue bad programmers like the poster who suggested node as a solution are the problem.
Sorry but you are wrong. I bet you $10000 that this very content management system has a securty whole somewhere as large as anything which is due to some behavior of PHP. PHP is inherently unsecure and it should be legally banned from being used in anything software. As for languages & frameworks that are inherently secure and still easy to pick up, try RoR, Python/Flask or Django.
I'm sure someone would look at WebGoat, and respond with, "OMG, Java is teh suckz!"
Well, they wouldn't be wrong, even if they were clueless.
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.
I'm in a similar position to you in terms of my experience and while I fully (or at least mostly) understand the flaws in PHP I don't expect very much from a scripting language to begin with. I believe that when it's done properly it's an adequate solution for many situations. There are certainly better tools from a programming perspective but from a product production perspective PHP is just one tool available in the box. I know mission critical projects that rely exclusively on VBA for instance. It's not elegant or even good but it works as required. PHP is not my first choice for ground-up projects (far from it) but I find it to be a very rapid tool to use to create a front-end for a distributed database for example. If I'm creating something from the ground up then I'll avoid it but that's not always the position I'm in. I fundamentally don't understand hatred of a single language or approach, I feel like I've got better things to get my knickers in a knot over. If I'm asked to work on a project that I feel is fundamentally flawed (which is quite a few to date) then I'll state my concerns and see how they're interpreted. If I'm ignored then I'll pass up the project, if not then I can find better approaches if necessary, this seems to me to be the most pragmatic method of selection.
Also: cancer isn't contagious.
Parameterized queries do since SQL problems and only idiots use strong concatenation for queries.
$A = "PHP";
$B = 5;
$C = " is garbage ";
$result = $B + $C;
$result = $A + $result;
Let's face it... It's just error prone junk! And yes, I've worked with PHP a very long time. Thank god those days are over.
I switched away from Joomla to WordPress several years ago because hackers kept banging on my virtual doors. I'm looking into switching from WordPress to a static file generator. Can't hack what doesn't have any vulnerabilities.
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.
It doesn't have to be like this. All we need to do is make sure we keep talking.
How is this news?
PHP: by amateurs, for amateurs.
Only self-trained monkeys use PHP.
It is great for one thing: If PHP shows up on a resume it gets deleted on the spot.
Oh, you need to replace this with a real_escape, because some moron thought it was a good idea to keep this trash instead of actually designing a consistent language.
It is not the SQL databases that are a security issue.
It is the use of substandard languages like PHP to create statements and a whole lot of stupidity.
NoSQL has its place and when I use it, I just use Postgres because it is much faster than mongodb. The only NoSQL type I probably wouldn't use it for are for graph databases, which are fairly esoteric.
PHP is shit, but server-side JS is not that much better.
I've just had a quick look at this. I really don't think this is a silver bullet. It's probably better than Joomla (not exactly setting the bar high here though) and the code is fairly clean to look at from my quick poking through on their github. The documentation is very scarce, so this spiel is from me skimming through their source code. I may have gotten some of this wrong; please rebut me if so.
Apologies for anon, I've been lurking on slashdot for years and really can't be bothered to make an account. I've been writing PHP and Javascript for money for about 10 years now along with smidgens of C, C#, Erlang, Ruby/Rails and Actionscript here and there.
The only real security advantages over any other PHP framework I can see is that it has been audited by a "Dutch IT security company" and that it prevents cross site request forgery (and to be honest, I'm just going on the fact that it calls a prevent_csrf function in the index.php entry point on that one).
The front page also claims to also prevent XSS and SQL injection, but from glancing through the code, I really can't see anything that actually does that. The only things I've seen that are even vaguely to do with this are that the views are rendered with XML and XSLT instead of raw HTML littered with <?= $somevar; ?> and the fact that they use mysqli->bind and mysqli->execute throughout their code.
Saying this up front; I've never used XSLT. I've sure read a fair amount about it and had to use various XML libraries and technologies built on top of XML. I've never heard of XSLT somehow magically preventing XSS - although to be fair ANYTHING is better than using core PHP. I'm not even sure how the heck you WOULD 100% guarantee that there's can never be XSS short of parsing your own views and working out what (potentially nested) context you're in when doing your string replacements and using the appropriate escaping. One thing I do know though; anytime you involve XML in ANYTHING you're opening yourself up to a new pantheon of weird and wonderful security vulnerabilities (xpath injection, external DTDs etc., etc.) that you need to take into account. I'd imagine XSLT is no exception. Someone PLEASE correct me if I'm wrong here, like I said, XSLT noob and genuinely interested in how the hell you would completely eliminate XSS without dragging your performance into the gutter.
As for the SQL Injection prevention; the framework uses parametised queries. Good Job! It also doesn't do any of the SELECT ... WHERE IN binding shenanigans that most frameworks do either*. This is also good. What is this framework doing to stop developers from shooting themselves in the foot when they're writing THEIR queries? Most frameworks handle this by discouraging their users from having to write SQL queries in the first place with some kind of ORM or something similar. It still has the problem of making the developer have to remember to bind parameters from I can see. Anytime a programming environment makes the developer have to be vigilant of something, it's guaranteed that someone, somewhere is going to screw it up.
Aside from the security side of things, there's also some major problems with this framework in terms of actually using it in a large/constantly evolving project that would put me off using it.
Firstly, from what I can tell, you WILL have to fork this framework eventually if you use it. There is no separation going on between the various page/cms/whatever models/views/controllers and the core system. They're in the same repository and there's no kind of module system that allows you to override them. You want to change any of them? You now get to choose between maintaining your own fork of the files changed (which won't do any kind of automatic merging of updates from upstream) or maintaining your own fork of the whole framework (which will periodically require you to deal with merge conflicts). Surely these should be split up into different repositories that would let you mix and match which ones you
I am a professional
Not based on the above post of yours, you aren't. While you make several good points, your method of doing so is not professional at all.
(Note that I do agree with several things you said, but not all, and certainly not with your way of saying it. And, after all, how you conduct yourself is an important part of being professional, so it is relevant.)
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 like you that much.
"So long and thanks for all the fish."
Oh I have been writing code for 30 years, on platforms embedded to large-scale mainframes, if a pissing contest is what you are after. See, SQL injections are not something any sane programmer wants to deal with on a daily basis. And no sane manager wants his coders to do that either because it is entirely unproductive work and above all risky to the point of risking your business at large. What you want is the ensuring trust in your tools that they handle all edge cases well as long as you stay in the standard. The trouble with PHP is that there is no standard: it all depends on a meriad of settings, compiler flags and circumstances. Hence a disease, not a tool. It's people like you who try to deflect the problem by claiming to be know-it-all-geniuses, giving management the false sense of grandess by employing the likes of you.
What does nodeJs have to do with apple?
I run nodeJs on a proper linux system, though it runs on windows and apple. I've never actually used a Mac computer before.
I'm running ubuntu at the moment.
All your fancy nosql databases are only useful once you pay another company hundreds of thousands of dollars to convert them in to SQL databases to run your queries against.
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 with quotes. The security_audit script sees when variables (possible user-input) is used to create a query string. Yes, SQL injection can be done by doing so, but if you chose to ignore the warnings, it's your own fault.
Banshee also has a good session library. Unlike the session handling in many other frameworks, this one works transparent with $_SESSION and stops session hijkacing.
No, there is no reason for me to fork it. The approach is simply different from many other frameworks. Others require to update/patch of a regular basis. In Banshee, the core libraries don't change much. They're safe and good. Just unzip the tarball, remove the default modules you don't need, add your own custom modules and the website is done. Many other frameworks allow you to run many websites with just one CMS installation. That's insane. With Banshee, every website has its own separate codebase. Who cares about a few MB's of harddisk space these days. It's harddisk space vs the certainty that my website remains stable. Updating the core CMS code because one website requires it might break others. Because of that, I happily waste a few MB's on my terrabyte harddisk to gain a lot of certainty and stability.
No, Banshee is not the ultimate solution or the silver bullet. But it is rock solid, fast and proven secure. I've built many websites with it, never needed to update / patch any of them and they all run or ran for many years without any trouble or any hack. And yes, many of them have seen a lot of hack attempts. And that's worth a lot to me. No Wordpress, Drupal or Joomla user can say the same thing.
It doesn't have to be like this. All we need to do is make sure we keep talking.
Which part of my above comment did you consider not to be of a professional nature? Calling PHP for what it is? Clearly stating reality as I see it? Distancing myself from technology that I consider not fit for purpose? The use of language that any non-techie understands, as opposed to those that claim "it's not the language it's the people", which does nothing but to cause further investment into non-viable technology? I fully stand by my statements. You may disagree with my arguments, or the use of language, or the overall position I take. However, this is certainly no basis for you to argue on moral grounds.
Yeah because injection exploits are impossible with javascript and CRUD?
any side JS is not much better.
Maybe we should just stop trying to build 'web apps' and kill off all these 'languages'.
Ruby? Python? gak. Slow as molasses.
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.
Why isn't the static analysis tools not mentioned in the documentation? I completely missed out on this because literally the only thing on the site that mentions it is the homepage which says "Since version 1.7, a security auditing script is included to verify that changes made to the framework have not introduced a security bug.". To me, that suggests that they run their own auditing script on their framework rather than it being a static analysis tool for the user.
Anyway, I've looked at it. It does three things:
There is so much wrong with how its doing the last part I'm amazed it works at all.
The core problem with it is that it's parsing PHP with regular expressions. This doesn't work. Regular expressions are for parsing regular grammars. PHP is not a regular grammar, it is a context sensitive grammar. You can do things like write recursive clauses in PHP which cannot be expressed in a regular expression (please don't mention perl extensions like lookarounds, you can handle a lot of non-regular cases with these but they're really ugly and really slow).
Here's some examples which will break this static analysis tool:
$ab2 = 'select * from
$query
$this->db->query("Select all from table where name IN (\"foo\", \"bar\") AND foo = $bar");
It really needs to be using this for its parsing: https://github.com/nikic/PHP-Parser and working off the abstract syntax tree it spits out. Rather than regexes.
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.
Does this include if it is used to spit out tainted data inside of contexts besides html text nodes/element attributes? The problem with XSS is that different contexts have different escaping rules. How would it cope with this example (convert from html)?
<a onclick="alert("<?= $foo ?>");">Say $foo</a>
(Yes, I know its a horrible example, but its something that nests contexts)
Most non-PHP frameworks I've worked with (such as rails) do the correct thing of defaulting to the secure behaviour (escaping all values as they're passed into the view) instead of the insecure behaviour PHP does (spit out the value as is). The problem is that they all assume they're inside a html text node, as they only see a string, instead of some kind of abstract syntax tree that can be used to work out the current context and apply the correct escaping behaviour.
SQL injection is prevented the same way. The SQL library won't accept queries with quotes. The security_audit script sees when variables (possible user-input) is used to create a query string. Yes, SQL injection can be done by doing so, but if you chose to ignore the warnings, it's your own fault.
See above.
Banshee also has a good session library. Unlike the session handling in many other frameworks, this one works transparent with $_SESSION and stop
PHP & PDO much? If you fail with that, it's not about the language.
Not quite. Cancer is (very) rarely contagious. But there are contagious cancers in animals and records of cancers being transmitted in humans.
Everything else you said... yep.
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.
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.
PHP is inherently unsecure and it should be legally banned from being used in anything software. As for languages & frameworks that are inherently secure and still easy to pick up, try RoR, Python/Flask or Django.
It's obvious that you're being a troll here, but I've got five minutes to spare, so what the heck, I'll bite.
This whole "PHP is inherently unsecure" thing is a pile of steaming bulls**t.
PHP *used to be* inherently insecure. It used to have features like "register globals" and you used to have to use the addslashes() function for SQL escaping. and.. and.. and.. And it's all been removed. The genuinely insecure stuff that created this reputation is no longer a part of the language.
Yes people do still mock it for some of the remaining quirks, and I'm with them on that. But you gotta get off that wagon of mocking its security because it really is a non-issue now. The PHP language today is barely recognisable from the PHP of a decade ago.
If people are still writing poor quality code in PHP, it can no longer be labelled as PHP's fault. Those kind of people would (and do!) write crap code in every language. PHP gets more than its share of those people because of its low barriers to entry, but that in itself isn't a problem with the language.
Except when you Google PHP and how to access databases, nothing about PDO comes up. All of the example code and tutorials are SQL injection friendly. The community around PHP is toxic.
> no longer part of the language
Nice try (language? Mess!).
This top answer on quora explains it nicely,
https://www.quora.com/Why-is-PHP-hated-by-so-many-developers
In fact, within a system cancer is highly contagious. The web is a system, clearly, and it is ill with the likes of Joomla or generally with PHP, in large parts.
You would get an object oriented database (not a particularly good one) if you googled my name with 'database'. but 'no', you had to assume I have no idea.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
The community on average is far less knowledgeable than e.g. that of C or derivatives. However, does that make the language *itself* bad? No. If you don't know how to use it properly, it's not the language to blame.
That being said, I do my best to move out of PHP, but I still find it the fastest choice in prototyping new things and creating fast internal tools for testing etc.
Unlike PHP, there is a very powerful and sane subset of Javascript and the rest can be ignored.
People who say JS sucks, usually mean the DOM sucks, which is independent of JS. Those folks also struggle understanding JS's object model. It really isn't that hard.
I would never use JS server-side but used properly it is very powerful client-side.
The official docs still recommend functions that are magnets for SQL injection and XSS.
The community is rotten from Lerdorf down to the dumbest little PHP dipshit.
Too bad PHP docs still recommend unfair functions for accessing the database and other things.
PHP: by amateurs, for amateurs.
Retard alert!
Both SQL and NoSQL DB have their time and place. There are many cases where the data hierarchy is unknown before runtime and this is where SQL databases fall down.
In fact, real databases like Postgres support several types of NoSQL.
I bet you didn't even know there are different types, key-value, document, graph, etc.
The fact that bullshit even exists is proof enough that PHP is for retards.
To this day the PHP docs recommend a ton of insecure functions and practices.
It is still shit.
Both are much faster than PHP.
Bullshit.
Rails never, ever had an issue between GET and POST.
They supported both correctly.
There has been plenty of valid criticisms of Rails over the years, how about choosing one of those?