Millions At Risk From Critical Vulnerabilities From WordPress Plugins

First time accepted submitter dougkfresh writes "Checkmarx's research lab identified that more than 20% of the 50 most popular WordPress plugins are vulnerable to common Web attacks, such as SQL Injection. Furthermore, a concentrated research into e-commerce plugins revealed that 7 out of the 10 most popular e-commerce plugins contain vulnerabilities. This is the first time that such a comprehensive survey was prepared to test the state of security of the leading plugins." It does seem that Wordpress continues to be a particularly perilous piece of software to run. When popularity and unsafe languages collide.

Comments

Not an unsafe language...

[dclozier]

Just bad coding. Any language can be coded with badly. (some more easily or accidentally than others)

Re:Not an unsafe language...

[ackthpt]

Just bad coding. Any language can be coded with badly. (some more easily or accidentally than others)

Well, yeah, other than [INSERT FAVORITE LANGUAGE HERE]. Any programmer worth his or her salt knows that language has all sorts of obvious safeguards against this sort of thing if you have even the vaguest clue what you're doing, which makes it that much more betterer and you should all use it right now and hire me for lots of money.

Assuming management or the analyst who specs the code gives the coder sufficient time to do it right.

Something I continue to observe in outsourced code is an incredible sense of optimism regarding security. Not because the coder is a fool (well, he/she might be) but because security and good practices are not emphasised, time and cost of up front development are too often the deciding factors.

Re:Not an unsafe language...

[Giant Electronic Bra]

Some encourage it more than others, and some provide security-oriented features. For instance perl's taint mode is a great security feature. Truthfully strong typing and mature frameworks go a long ways, IF you know how to use them.

HOWEVER all this is secondary. The appalling thing is THAT NONE OF THESE PLUGINS WERE EVER AUDITED. Any webapp is almost sure to have some sort of hole in it. You can plug them but its tricky and no team will find them all. The question then is how on God's Green Earth have so many people deployed this stuff and not audited it thoroughly (or at all)? I taught web-app security and was one of the earliest people in the business, I'd never in a million years deploy one of these plugins for a client and not beat it to death with a fuzzer and 10 other things. This is just basic crap I was teaching in my college courses 8 years ago (and it wasn't exactly revolutionary then). Hell, I don't consider myself any sort of security genius by a long shot, but all I can say is that there are a lot of scarily ignorant fools out there...

Re:Not an unsafe language...

[chuckinator]

Auditing isn't cool and takes time that could be better spent posting pictures of food with a sepia filter on Instagram.

Every language is unsafe.

[Qzukk]

It's just that PHP has managed to attract a huge number of absolute retards who do things like evaluate image files (it WAS an image file you uploaded, right? It ended in .gif, right? So it's totally an image file and I shouldn't even be bothered to verify the contents because nobody would ever upload php code ending in .gif) in order to dump the contents out to the browser instead of using ANY of the multiple functions or methods to do just that securely.

Re:Every language is unsafe.

[cold fjord]

More like every language can be used unsafely, and some have built-in weakness in addition. The C language and many of its derivatives have a number of issues that are well known and documented. In that regard both Unix and C are like chainsaws - in skilled hands they make short work of difficult problems that might be far harder or impossible with other tools, but let your attention wander for a moment and you are missing a leg.

Re:Every language is unsafe.

[dkleinsc]

Every language is unsafe, but some almost try to be as unsafe as possible.

For example, the oldest (and until fairly recently, only) way of handling database queries in PHP pretty much asks for you to be vulnerable to SQL injection attacks, because there's no parameterization so all you can do is awkwardly run a hodgepodge of escaping functions and hope they work. By contrast, Perl, Java, Python, and C# all provide support for parameterizing queries in their standard approaches to handling database queries about 10 years before PHP did. That's the kind of thing that gives PHP its bad reputation.

Re:Let's keep the tree green

[amicusNYCL]

The solution is easy: hosting providers should be required

The solution is authoritarian.

Re:In case you were wondering...

[Zedrick]

I used to be of the same opinion, but... I've been working in the hosting business for 10 years now, and that kind of attitude doesn't really work in real life.

It's 2013, most people (at least in developed countries with high IT penetration) have their own domain and website nowadays. Do you really think it's fair to call a 50 year old woman who wants a nice website for her cat-blog a moron? Or the coin collector who don't care about computing but just want to write about English hammered coins? Or the fishing club whose members wants a nice looking site with a gallery and perhaps a public calendar? Or the girlfriend who wants to blog about cooking? Are they all morons?

Websites are not just for companies or IT-people anymore.

Also, Wordpress is way way better than it used to be a few years ago (unlike Joomla which is a total fail in every version). Since 3.5.1 was released, I've seen more customers hacked due to brute force logins than security exploits in outdated themes or plugins.

Ooh, scary Open Source, look at the nasties

[xenoc_1]

Great, Dice posts story from a corporate-software-industrial-complex advertorial mag, with a link to their so-called blog. Which ironically is running WordPress, along with a bunch of common plugins like "Yoast WordPress SEO plugin v1.4.7" and "All in One SEO Pack 1.6.14.6". Right there tells me how clueless they are about WordPress, because unless you have a damn good special reason, you do not want to be running two separate SEO plugins. LeadGen contact form plugin, a bunch of ad and analytics beyond the usual, and no apparent caching plugin. Oh, and no Google Authorship id done the correct way, despite both of those SEO plugins having "fill in the blank" prompting for it (they do have an XFN tag on their contact info but don't do the full Google social.)

For more laughs, their verison of All-In-One SEO is downlevel. Exactly what Checkmarx themselfes warn agansit. They are on 1.6.14.6, current version is 2.0.2.

Yeah, I'm gonna listen to them about WordPress security.

When you click through their blog to the actual PDF report, guess what? They redacted the names of all those "at-risk" plugins, noting only 6 by name. Four of which they claim took their advice and fixed the problem, and two (WP Super Cache and W3 Total Cache) which I recall getting fixes for months ago. Hot news. I guess that even though their supposed expertise is in scanning for vulnerabilities, they are not going to tell you which are at risk in the current environment, because you didn't pay them. Classic dipstick move. Total and utter unawareness of the karmic and $$ benefits of internet "gift culture", such as, the whole damn open source movement and the specific WordPress ecosystem in which they are supposedly expert.

But we should listen to them, because: Checkmarx was recognized by Gartner as sole visionary in their latest SAST magic quadrant and as
Cool vendor in application security.

Which Ones?!?!

[Rob Riggs]

What an absolutely useless article and report. Scaremongering at its best, with no actionable content. Which plugins have vulnerabilities? Can they be mitigated through configuration changes or do they need to be disabled/uninstalled? What is the potential exposure? Those are the sort of things a computer professional needs. Where are the damned CVEs?