Forgot your password?
typodupeerror
Security PHP

Millions At Risk From Critical Vulnerabilities From WordPress Plugins 145

Posted by Unknown Lamer
from the just-use-ur-web dept.
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.
This discussion has been archived. No new comments can be posted.

Millions At Risk From Critical Vulnerabilities From WordPress Plugins

Comments Filter:
  • by dclozier (1002772) on Wednesday June 19, 2013 @01:49PM (#44051999)
    Just bad coding. Any language can be coded with badly. (some more easily or accidentally than others)
    • by Anonymous Coward on Wednesday June 19, 2013 @01:54PM (#44052051)

      It's not bad coding, those are just misunderstood features. SQL Injection? - That's just a back door we left in for convenience.

    • by Anonymous Coward on Wednesday June 19, 2013 @01:56PM (#44052079)

      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.

    • by Giant Electronic Bra (1229876) on Wednesday June 19, 2013 @02:11PM (#44052227)

      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...

      • by chuckinator (2409512) on Wednesday June 19, 2013 @03:20PM (#44053027)
        Auditing isn't cool and takes time that could be better spent posting pictures of food with a sepia filter on Instagram.
      • by indeterminator (1829904) on Wednesday June 19, 2013 @03:34PM (#44053189)

        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)?

        Because your client will want new plugins every week, gets tired of asking you everytime, and wants you to set up the permissions so that the GUI plugin installer works ("what do you mean not a good idea? the last site I had worked that way and I never had any problems with it"), then proceeds to install all the plugins he needs to make his blog on cats and other larger-than-life stuff buzzword compatible.

      • by ArcadeMan (2766669) on Wednesday June 19, 2013 @03:42PM (#44053281)

        There's so many aspects to everything, you cannot assume everyone is an expert on all areas required. You focus a lot on the security but I can bet your plugins would probably be extremely hard to integrate and use, look like crap and be a usability nightmare.

        • by Giant Electronic Bra (1229876) on Wednesday June 19, 2013 @04:18PM (#44053657)

          No, I wouldn't write them, I'd just security audit the ones I use. Its just insane to drop in an untested configuration of a webapp doing e-commerce. I don't care that someone else wrote it, I ASSUME they are security-incompetent and test.

          Granted, other people's responses to my post definitely explain why this crap happens, but it doesn't make it any less scary or eye-rolling. The real problem is people just don't have any idea how bad the stuff they can install free on their servers really is, unless they've had some education on it. Most people never get that (and how would they know they want it). So you have this kind of yuck. What we need are some webapps written with the mindset of FreeBSD, totally audited and known good code supplied from a single auditor. In fact the webapp world needs this MUCH MORE than OSes do.

          • by ArcadeMan (2766669) on Wednesday June 19, 2013 @05:17PM (#44054161)

            So what we need is a new language targeted at the Web with security being the first design rule.

            The language has to do everything to protect itself and the server, the programmer only calls dark boxes to do what he wants, i.e. no direct access to databases and similar insecure things.

            Why is it the programmers who are supposed to never trust their input data? Shouldn't that be the job of the language itself? I bet the language designers, who would only need to do it once and make it built-in, would do a much better job than ten million programmers of various degrees of competency around the world.

            • by real-modo (1460457) on Wednesday June 19, 2013 @11:11PM (#44057045)

              SQL Injection

              What we need is for MySQL/MariaDB, PostgreSQL, FireBird, etc., to come configured so that database updates can only take place in stored procedures in which statement building isn't present; and that they also come configured so that when you create a database, two users/roles are created: a role with stored procedure execute privileges only, and the owner, and the database owner can only access the database through the command-line interface.

              In other words, what we need is for web programmers to be forced to learn something about the tools they're using.

              You might get that effect by inventing a suitable replacement for SQL and forcing people to use it. But I think they'd just use text files for backing storage.

              Cross-site Scripting

              I can't see how a new language stops this.

      • by dgatwood (11270) on Wednesday June 19, 2013 @04:22PM (#44053697) Journal

        The appalling thing is THAT NONE OF THESE PLUGINS WERE EVER AUDITED.

        Does this surprise anyone? There's a good reason why WordPress systems are popular targets for hacking....

        That said, to some degree, I blame the language designers for not being more aggressive at forcing people to upgrade their old-style SQL queries to use a more modern, parameterized syntax.

        If you really want the web to be more secure, we should:

        • Eliminate the PHP/Perl/Python mysql extensions. Force everyone to rewrite their software with either mysqli or PDO. Period.
        • Add tainted data tracking into the language runtime for PHP, Perl, Python, etc. This means:
          • All data coming from outside the code itself (from all files, from GET/POST request fields, etc.) is marked as tainted.
          • String concatenation of tainted data with untainted data results in tainted data.
          • Variable substitution of tainted data inside a string results in a tainted string.
          • Taint is preserved across function calls, such as explode/implode.
          • Data can only become untainted by casting it to a numeric type. (No, mysql_real_escape_string should not untaint anything. That function is a hack. You shouldn't be using it in production code.)
        • All mysqli and PDO functions/methods should throws an exception if a tainted string is passed as a format argument.
        • When the language is running in a web server, all output to stdout (to a browser) should similarly throw an error unless the taint type matches the current Content-Type value. For example, if the headers say Content-Type: text/html, then input from an HTML file is not tainted. Input from a database or text file should have to be either quoted for output or sanitized through your choice of sanitizer functions, tailored for various purposes (e.g. an anti-XSS sanitizer).

        And so on. These changes would go very, very far towards eliminating SQL injection attacks and XSS. The fact that such protection schemes are both incomplete and disabled by default in most programming languages suggests to me that security is not a high enough priority.

        IMO taint protection should be part of the default configuration when running in a web server environment. If there are bugs that make that impossible, then those should be the absolute highest priority bugs on the plates of the language engineers.

        In the meantime, everyone should add taint_error_level = E_ERROR to your php.ini file, etc.

        • by Giant Electronic Bra (1229876) on Wednesday June 19, 2013 @04:37PM (#44053847)

          Agreed. At least with Perl there IS a taint mechanism and it generally works as you describe (IE you can only untaint data by explicitly calling 'untaint()' or running it through a regex). If you properly use layers like Class::DBA you should never need to compose SQL or have SQL generated in-app, you should be entirely in bind-parameter land (and even that is normally hidden from view). I wrote an entire CMS/e-commerce platform in Perl 15 years ago using those tools. AFAIK no security holes were ever uncovered once we had finished our developer audits, and it was considerably more capable than Wordpress (though there are some nice tools available today like wiki-syntax parsers and XSLT that we didn't have in 1999) with fully apartment hosting and role separation and a bunch of other features that were totally unknown back in those days. Ironic how our thoroughly tested platform is dust now and a giant PoS like Wordpress lingers on. I told them to go open source... ah well.

          • by dgatwood (11270) on Wednesday June 19, 2013 @04:51PM (#44053969) Journal

            IMO, running it through a regular expression shouldn't untaint it, either, unless that happens to be a regular expression specifically designed to quote strings properly for output. But yes.

            The biggest problem is that young white hat hackers are few and far between. We don't spend nearly enough time in college courses learning about proper security, and as a result, folks come out of school not knowing it. By the time they actually "get" security, most of them are well on their way to retirement, and they aren't always keeping up with the latest programming languages. Unfortunately, most web technology development tends to be done by people straight out of school, because it is a cutting-edge field that is constantly evolving. The result is that the people who understand security often don't understand the web tech, and the people who understand the web tech often don't understand security.

            IMO, any college that does not require at least a semester of computer security (ideally, two) for a BS degree is doing their students a disservice. It is a crucial subject for anyone who has any interest in writing software, and it is an area where competent engineers are seriously in demand.

            • by The Cat (19816) * on Wednesday June 19, 2013 @05:29PM (#44054323)

              aren't always keeping up with the latest programming languages

              This is the problem right here. The "latest programming language" is buggy crap.

              • by dgatwood (11270) on Wednesday June 19, 2013 @06:31PM (#44054947) Journal

                Ah, but the latest programming language is buggy crap because the senior people aren't pushing to improve it and the junior people lack the skills. It's a Catch-22/chicken-and-egg sort of problem.

                • by ttucker (2884057) on Wednesday June 19, 2013 @06:59PM (#44055267)
                  The world needs the next programming language like I need to have 12 more anuses on my body.
                  • by dgatwood (11270) on Wednesday June 19, 2013 @11:19PM (#44057089) Journal

                    <sarcasm>But you'd be a superhero. We could call you Rectum Man. "My plants were all dying for lack of fertilizer, and I didn't know what to do. But then Rectum Man came to help. Thank you, Rectum Man!" Everyone needs 12 more anuses. Everyone.</sarcasm>

                    What it comes down to is best summarized by this obligatory XKCD [xkcd.com]. Just s/standards/programming languages/g. Alternatively, s/standards/web frameworks/g. And so on. This is why we have Perl, PHP, Python, Ruby, and whatever else has come out since I stopped bothering to pay attention. Instead of improving what's out there, everybody wants to create the cool new thing. This inevitably results in lots of low-quality code.

                    • by Giant Electronic Bra (1229876) on Thursday June 20, 2013 @11:28AM (#44061073)

                      Yeah, I was sorely disappointed when we went from a concentration on Perl/CPAN as the main resource for building web apps to 32 different interchangeable scripting languages which require the same libraries to be written over and over again and each has its own bugs. I mean, sure, perhaps its arguable that Ruby is a better language than Perl, for example, but its not that big a difference and clearly far too little focus has remained on actually writing and maintaining secure webapp code.

                      But, nobody is in charge of the world. We get ridiculous perverse results in some cases. There's nothing for it but to keep trying. Meanwhile the redundant scripting language treadmill continues with Go, Dart, Processing, blah blah blah blah (and who can forget Perl 6!). No doubt some of them are modest improvements, but we tend to get set back to zero every time we have to adopt a new set of core tools.

                      Frankly I drew the line at Perl. I can build anything any client ever needs in it and it works fine. All that extra time my competition spent migrating to some newfangled thing was just gravy for me. All I can say is I'm glad I don't deal directly in retail webapps anymore. The whole market is shit.

                    • by The Cat (19816) * on Thursday June 20, 2013 @12:09PM (#44061451)

                      The software market needs a return to basics.

                      There's a reason we still use grep. Because it was engineered properly.

                    • by Giant Electronic Bra (1229876) on Thursday June 20, 2013 @01:06PM (#44062101)

                      Yeah, agreed. I'm an old FORTH programmer, talk about basics. We got more done with that tool at a faster rate BY FAR than any other tool chain in the past 30 years.

      • by ttucker (2884057) on Wednesday June 19, 2013 @06:56PM (#44055243)
        So the code passes every audit in the book with a hacked together solution to each detected problem, do you really fee any safer? Auditing tools are fine, but certainly provide some false sense of security.
    • by Warbothong (905464) on Thursday June 20, 2013 @01:30PM (#44062319) Homepage

      Not an unsafe language...

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

      "Bad coding" is similar to "no true Scotsman"; the goalposts are movable in hindsight. What really matters is how easily we can spot potentially-insecure code when we're browsing a codebase *before* it is exploited.

      Let's say our codebase contains, somewhere deep inside, a C function which tramples over unallocated memory. How likely are we to spot this bug as a maintainer, who may occasionally open the file for unrelated purposes? Not very, since unsafe C code looks pretty-much the same as safe C code.

      Likewise our codebase could contain a PHP function with an XSS vulnerability. How likely are we to spot that? Again, not very.

      Now let's say our codebase contains a PHP function which tramples over unallocated memory (via PHP, not due to some buggy C library). How likely are we to spot that? Very likely, since it would appear pretty bizarre, even if it weren't buggy. This makes PHP more memory-safe than C.

      The underlying reason PHP is unsafe when it comes to Web programming is that it treats everything as strings. User input, SQL queries, HTTP headers, HTML, regular expressions, filenames, code, variable/class/method/constant/function names and so on. Implicit conversion even allows non-strings to be treated as strings. With everything implemented as a strings, programmers think of their data as strings instead of what they actually are (HTML attributes, unsafe external input, etc.). This leads to string-based interfaces, which beget more string-based interfaces in the name of compatibility, and any non-string interfaces (eg. SimpleXML) end up with string-based escape hatches which force us to carry on thinking in terms of strings. When everything is a string, nobody knows what their data actually *is*. Has this SQL query come from the outside world? You'd better hope not, since you've just sent it to the database!

      The really twisted part is that, in a world of strings, the "solution" to security is escaping. Actually escaping is just a symptom; escaping a string just gives us another string! We gain no information by escaping; we go from data that's potentially unsafe to data that's potentially garbage (double-escaped). What's the solution to the double-escaping problem? Remove some escaping! Escaping must be done exactly once, but good programming practice makes us split up our applications into many small, reusable pieces. This means that the vast majority of any codebase *cannot* escape its data, for fear of double-escaping. Thus the majority of our code must either trust that its input is safe, or trust that someone else will escape its output for us. This is the case no matter how security-minded we are.

      However, the nature of programming is to plug other people's things together in ways they didn't anticipate. Doing otherwise would just be reinventing the wheel. No wonder that form inputs get plugged straight into databases! The input-reading functions are compatible with the database-querying functions! Why should I worry about security when the functions I'm using have been written by the world's foremost security-minded PHP programmers? They know more about this stuff than I do, so I'd rather plug their stuff together than put my own naive code in between!

      This ecosystem is why PHP is more-unsafe than, for example, Java (which is less-unsafe), Haskell (which is even-less-unsafe) and Agda (which is much-less-unsafe).

      In a system where different languages have their own specific types, we can't just plug a form input into a database. We need to convert an "UnsafeInput" into an "SQL"; the path of least resistance would be to use an escape function. There's also no danger of double-escaping, since an escaping function can't consume its own output without it getting converted back first. Such undesirable outcomes are still *possible*, but require manually working-around the provided mechanisms. Such co

  • by Qzukk (229616) on Wednesday June 19, 2013 @01:49PM (#44052003) Journal

    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.

    • by cold fjord (826450) on Wednesday June 19, 2013 @02:03PM (#44052143)

      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.

    • by tepples (727027) <tepples&gmail,com> on Wednesday June 19, 2013 @02:19PM (#44052295) Homepage Journal

      it WAS an image file you uploaded, right? It ended in .gif, right?

      I want to become something other than one of these "absolute retards" you mentioned. If GD returns sane values for the image's width, height, and MIME type [php.net], what dangers should I still be aware of?

      • by MtHuurne (602934) on Wednesday June 19, 2013 @02:40PM (#44052535) Homepage

        That's the wrong question: instead of performing a dangerous operation only if the input doesn't look suspicious, you should not perform the dangerous operation at all. So if the input data is supposed to be an image, pass it to a function that can only process images. That way, if an attacker does manage to sneak in PHP code disguised as an image, it will just trigger an error condition instead of being executed.

      • by Anonymous Coward on Wednesday June 19, 2013 @02:41PM (#44052541)

        They could exploit GD.

        The only solution is to have the user base64 encode the binary GIF data, print it and then snail mail it to you.

        You can then build a dedicated PC that's not on the network, type out the base64 data, decode it and confirm it's a valid GIF. Then connect that PC to the network and upload the GIF on behalf of the user.

        If the GIF was malicious you simply set that dedicated PC on fire, inform the user (via snail mail) "INVALID GIF IMAGE, PLEASE TRY AGAIN" and then buy another dedicated PC for the next GIF you receive.

        It's the only way to be safe. I do this with my site and so far so good: I launched one year ago and I've received 1 GIF so far 3 months ago and I'm about 75% done typing all the base64 data. I hope to confirm his avatar picture by July 1st!

      • by SirGarlon (845873) on Wednesday June 19, 2013 @02:51PM (#44052657)

        I can't answer your specific question (I am mostly ignorant of PHP), but perhaps I can be of help with the broader issue of helping people learn about secure coding practices.

        One of the basic principles of secure coding is to validate user input to ensure it is what you expect. If you are checking the image size and MIME type you are headed in the right direction. Whether you've gone sufficiently far, I'll leave to PHP experts.

        To get started learning more, you can do worse than the OWASP Top 10 [googlecode.com] (PDF) -- skip to page 5 to bypass a thicket of jargon that may confuse you at first. Probably other readers can suggest other, gentler, starting points. I am suggesting the OWASP Top 10 because it's commonly cited and because it discusses how to prevent each of the major classes of application vulnerabilities. It's not perfect. It will take some time and thought for a newcomer to digest, but for me the effort was worth it.

        You can also go to OWASP meetings if there is a chapter near you, or maybe find a local PHP user's group and ask about security.

      • by Qzukk (229616) on Wednesday June 19, 2013 @04:40PM (#44053875) Journal

        For gods sake, don't include() it to send it to the browser, because it could be a valid image with in an EXIF tag.

    • by dkleinsc (563838) on Wednesday June 19, 2013 @02:50PM (#44052645) Homepage

      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.

      • by Dragonslicer (991472) on Wednesday June 19, 2013 @04:50PM (#44053959)

        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.

        Depends on your definition of "fairly recently." PDO was available as an extension for PHP 5.0 (2004) and was included in the standard installation for PHP 5.1 (2005). There hasn't been any excuse not to be using it for at least 5 years.

    • by cjjjer (530715) <<cjjjer> <at> <hotmail.com>> on Wednesday June 19, 2013 @02:52PM (#44052669)
      I hate to say it but it sounds like PHP is the new classic ASP with regards to exploits...

      Not that I am saying classic ASP devs got any smarter they just moved from ASP to other forms of server scripting/languages.
      • by V for Vendetta (1204898) on Thursday June 20, 2013 @12:15PM (#44061523)

        So, you're saying that idiots that couldn't code ASP can't code PHP. Color me suprised then.

        ASP (or better ADO) has provided prepared statements [microsoft.com] for a long time. Not using them is not ASP's fault.

        Create a stored procedure and swap

        cmdPrep1.CommandText = "UPDATE titles SET type=? WHERE title_id =?"
        cmdPrep1.CommandType = adCmdText

        in that snippet for

        cmdPrep1.CommandText = "name of stored procedure here"
        cmdPrep1.CommandType = adStoredProc

        and you're even better.

  • by schneidafunk (795759) on Wednesday June 19, 2013 @01:55PM (#44052065)
    According to the PDF [checkmarx.com], e-commerce plugins are in the list. I'm a bit surprised to see that, as I assumed developers would be thinking about security first with e-commerce.
    • by Vanderhoth (1582661) on Wednesday June 19, 2013 @02:01PM (#44052123)
      I agree it should be the first consideration, but the people who want the implementation are MBAs that care more about getting people's money, return on investments and how something looks rather than how secure it is.

      <sarcasm>Why pay money up front for security you might never need? It's better to wait until something does happen, like millions of credit card nubmers are stolen, and give the money to the PR people to clean up the mess. It's way cheaper if the gamble pays off.</sarcasm>
    • by Bogtha (906264) on Thursday June 20, 2013 @02:33PM (#44063191)

      I assumed developers would be thinking about security first with e-commerce.

      These are developers who, when faced with the problem of how to build an e-commerce site, think "I know, I'll use my favourite blogging software". Assuming they can tie their shoelaces is a stretch, let alone thinking about security.

      Right about now, somebody is champing at the bit to reply saying that Wordpress has outgrown its blogging roots and is now a proper CMS. I invite anybody tempted to believe that nonsense to look at Wordpress' database schema [wordpress.org] and make their own mind up.

  • by dkegel (904729) on Wednesday June 19, 2013 @01:57PM (#44052089) Homepage
    The solution is easy: hosting providers should be required to continuously run vulnerability scanners, and instantly take down any sites which have known vulnerabilities. As a bonus, it would clear out a lot of crap sites.
  • by xenoc_1 (140817) on Wednesday June 19, 2013 @02:27PM (#44052393)

    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. [wordpress.org]

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

    When you click through their blog to the actual PDF report [checkmarx.com], 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.

    • by St.Creed (853824) on Wednesday June 19, 2013 @03:43PM (#44053289)

      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.

      Visionary just means they paid Gartner. The Cool vendor means they took 'em to a brothel as well.

      Okay I'm joking. Still... the fact they were whoring out "pattern based stragegy" (you had to pay to use the term) not long ago leaves me wondering.

  • by TheSkepticalOptimist (898384) on Wednesday June 19, 2013 @02:30PM (#44052435)

    People complain about IE6 or Flash or Java, but every web developer I know ABHORS WordPress.

    The moment a company decides to use Wordpress as their underlying site "technology", its game over. This was supposed to be a product that allowed people at home to set up a content site quickly, not an enterprise level technology.

    So if this thing is causing significant security issues, it should be placed at the top of the Internet's most hated and avoided like the plague.

    If you want to blog online, use Facebook or Twitter or any other established social platform, nobody sets up their own blog anymore, that is so early 21st century.

    • by amicusNYCL (1538833) on Wednesday June 19, 2013 @02:53PM (#44052683)

      nobody sets up their own blog anymore, that is so early 21st century.

      Shit, is it mid-century already? Where the hell does the time go?

    • by realityimpaired (1668397) on Wednesday June 19, 2013 @03:21PM (#44053039)

      If you want to blog online, use Facebook or Twitter or any other established social platform

      Maybe I don't want the advertising that goes with a platform like that, or the space limitations, or the way they assert copyright on the stuff I create, or maybe the WP blog is just a front-end for a domain name that's primarily there for e-mail, or...? There's a lot of reasons to run something like WordPress, and social media as you suggest is not a fix-all substitution.

      Besides, it's not like Facebook and Twitter have never been hacked... they're big juicy targets with the number of users they have and the amount of information they're collecting about their users.

    • by LordThyGod (1465887) on Wednesday June 19, 2013 @03:25PM (#44053091)

      The moment a company decides to use Wordpress as their underlying site "technology", its game over.

      Like CNN, NYTimes ... ?

      This was supposed to be a product that allowed people at home to set up a content site quickly, not an enterprise level technology.

      Actually originally and for a long time, it was a blogging platform ... for people who write blogs. Not really for housewifes and the like.

      So if this thing is causing significant security issues, it should be placed at the top of the Internet's most hated and avoided like the plague.

      "if" ? If your aunt had a dick she'd be your uncle.

    • by Jason Levine (196982) on Friday June 21, 2013 @02:00PM (#44072095)

      People complain about IE6 or Flash or Java, but every web developer I know ABHORS WordPress.

      Hi there. I'm a web developer. Nice to meet you. There, now you know a web developer who likes (and extensively uses) WordPress

      The moment a company decides to use Wordpress as their underlying site "technology", its game over. This was supposed to be a product that allowed people at home to set up a content site quickly, not an enterprise level technology.

      WordPress was originally designed as a blogging platform for people to set up blogs easily, but has grown over the years to be a major CMS tool.

      So if this thing is causing significant security issues, it should be placed at the top of the Internet's most hated and avoided like the plague.

      To be fair, the article is saying that WordPress PLUGINS were to blame, not WordPress itself. Plugins can come from anyone and aren't audited by Wordpress at for things like SQL Injection attack risk. Whether they should be or not is another conversation. Of course, there are many security-related plugins for WordPress so I'd love to see a "SQL Injection Attack Detector" plugin that would scan other plugins and report to the admin/webmaster/whoever when it finds something. (Whoever wants to develop this, you can use my idea for just a lifetime license to your plugin.)

      If you want to blog online, use Facebook or Twitter or any other established social platform,

      Facebook and Twitter aren't really blogging platforms. Facebook comes close, but I stay off of it because I don't like many of their privacy (and other) actions. At best, Facebook is an add-on to a blog.

      Twitter is micro-blogging, not blogging. You can't post an in-depth article about your favorite subject on Twitter. Not, at least, without breaking it into a hundred consecutive tweets which would just be annoying.

      nobody sets up their own blog anymore, that is so early 21st century.

      I'm sorry, but I have to disagree. I use WordPress for my blogging activities because I can be guaranteed that my WordPress blog will be around 10 years from now (assuming I want to continue it). I can't guarantee that Facebook won't collapse in a few years or modify things to such a degree that my blog is unusable. Besides, if my blog was hosted by a third party service, they could disappear at any moment and I'd lose everything. My WordPress blog is backed up to my computer every night. If my hosting provider disappeared, I'd be momentarily inconvenienced (as I found a new provider and set everything back up), but I'd lose at most a day's worth of content.

      Whenever anyone comes to me looking to set up a site, I always recommend getting a hosting account and setting up their site, not sticking their site on some third party service. (A client of mine recently had one of their staff redesign their site without consulting me. It went from a WordPress site which did need some visual work done to a cookie cutter "webs.com" site with such brilliant ideas as having credit card information submitted on a HTTP form via e-mail. The guy who did it insisted he was a "web developer." Sadly, to him, this means "I can open this account and click where they tell me to click in the template.")

      • by Jason Levine (196982) on Friday June 21, 2013 @02:13PM (#44072249)

        Of course, there are many security-related plugins for WordPress so I'd love to see a "SQL Injection Attack Detector" plugin that would scan other plugins and report to the admin/webmaster/whoever when it finds something. (Whoever wants to develop this, you can use my idea for just a lifetime license to your plugin.)

        Replying to my own comment, but after writing that, I did a quick search and found this plugin: BulletProof Security
          http://wordpress.org/plugins/bulletproof-security/
        It claims to protect against SQL Injection attacks. I can't vouch for it personally, but it did get 448 five star reviews out of 507 reviews. That's got to count for something. In any event, it goes to show that, while some plugins can cause trouble (via SQL injection openings and other bad coding), there are other plugins on the market designed to protect your WordPress website. No WordPress site should be set up without appropriate protections (the same as any non-WordPress site). In this case, "appropriate protections" might include some security plugins.

  • by Medievalist (16032) on Wednesday June 19, 2013 @02:38PM (#44052511)

    Never use a module if you can possibly avoid it, and keep everything you use patched up to date.

    That way you'll be as safe as you can be - because you'll only be using modules you aren't actually capable of writing yourself.

    Pulling in a dozen wordpress plugins (or a dozen CPAN modules, or the Ruby or Python equivalents) so you can avoid learning how to unpack a trivial format is the road to software maintenance hell...

  • Which Ones?!?! (Score:5, Insightful)

    by Rob Riggs (6418) on Wednesday June 19, 2013 @02:44PM (#44052581) Homepage Journal
    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?
  • by interval1066 (668936) on Wednesday June 19, 2013 @03:11PM (#44052919) Homepage Journal
    My wordpress blog might get comprimised. Let me jump right on that little emergency...
  • It seems like I read a version of this article about once a month. Seems like Wordpress is always not-too-far-away from some amazing catastrophe that will cause Western civilization to collapse.

    I have been looking around for a new blog platform in order to redo my personal website, which is an aging Joomla 1.x system (and actually works fine, thank you very much, I just wish the URLs weren't so awkward). As far as I can tell, the entire rest of the world abandoned everything other than Wordpress, but actually I'd prefer something that didn't seem to be semi-permanently at risk of critical vulnerabilities due to crap plug-ins or whatever.

    Right now, I'm looking favorably at serendipity, which seems simple and relatively safe. Joomla 2 isn't better in ways that interest me and worse in ways that do. I want no part of Drupal, and a lot of other stuff out there just isn't right for me. So, still looking actively at everything other than the blogging platform that is apparently in continous state of near catastophe.

    • by Geeky (90998) on Thursday June 20, 2013 @12:07PM (#44061429)

      I had a look at Concrete [concrete5.org], but to be honest it's the ubiquity of Wordpress that appeals to me. I avoid plugins wherever possible, and the ones I do use are mainly on the admin and content creation side rather than presentation of content.

      The popularity of it means that I can quickly find answers and code snippets when I want to do something, and I feel I have the experience to sort good suggestions from bad.

  • by pinkeen (1804300) on Wednesday June 19, 2013 @05:42PM (#44054481) Homepage
    Wordpress is the most popular web publishing platform and, IMHO one of the worst implemented pieces software. Last time I looked their coding practices were ancient (even by PHP standards). I know that popular stuff attracts crappy coders, but it's so crappy that it either will force you to write crap or frustrate you so much that you don't even care.

    The wordpress phenomenon never ceases to amaze me. I know it's nothing special, cause there's probably tons of crap in proprietary closed-source software that's even more popular - but then at least you can't see it.

    The only fix is a rewrite and they won't do it because it would break compatibility. (Or something?)

    DISCLAIMER: This post may be based on outdated knowledge. Maybe wordpress is state-of-the-art now with their shiny, perfect codebase.

I judge a religion as being good or bad based on whether its adherents become better people as a result of practicing it. - Joe Mullally, computer salesman

Working...