Skip to content ↓ | Skip to navigation ↓

Many websites have a WYSIWYG editor.

You may not even realise that you are using one, but – if you think about it – chances are that many of the sites that you visit allow you make forum posts, publish blog entries, post private messages, update wiki entries, submit support tickets, create signatures or leave comments.

All of these are very likely to incorporate some rich content elements.

WYSIWYG editor TinyMCE

Sure, it’s very nice to be able to embed images, or format your text with italics and hyperlinks, but is this flexibility unwittingly leaving a door open for attackers?

Security researcher Ashar Javed raised the issue in a talk entitled “Revisiting XSS Sanitization” at Blackhat Europe last week.

Javed, who has previously been awarded bug bounties after finding vulnerabilities on popular websites, used a simple methodology to test the web-based WYSIWYG editors used on many sites.

His plan? To see if he could trick a WYSIWYG editor into popping up a message-box containing the number “1” rather than sanitized content.

Some of the websites Javed examined relied upon third-party editor libraries and could potentially be being used on millions of other websites. All it would take was for one such editor library to have a vulnerability and attackers could have a field day.

It is some concern, therefore, to learn that Javed discovered that many WYSIWYG online editors proved to be vulnerable to cross-site scripting (XSS) attacks.

Commonly, web-based WYSIWYG editors were vulnerable to mischievous injections when it came to inserting and editing images, embedding URLS, uploading files and videos.

XSS in TinyMCE editor

One of the problems that Javed identified was that the developers of WYSIWYG editors think it is the responsibility of those developing the website or back-end server-side systems to perform the sanitization. Meanwhile, time-strapped website developers who pull a WYSIWG editor off the shelf and plug it into their site are imagining that all the hard work has been done for them.

Javed’s solution is to develop a so-called “Unbreakable sanitizer/filter” that does the tricky job of making sure content entered into WYSIWYG editors is safe – and cannot be used to exploit an XSS vulnerability.

If you’re curious, you can try out his XSS Filter, and try to bypass it with some JavaScript.

Javed ran an open challenge for two weeks, inviting anyone to attempt to bypass his filter with an XSS attack. During that time there were over 78,000 attempts recorded from 1035 unique IP addresses but nobody has managed it so far.

More details of Javed’s research can be found in this white paper [PDF] and in the slides he presented at Blackhat Europe.

If your company has a website, or relies upon a web application, that you think might be at risk be sure to take a long hard look at it and ensure that you are properly sanitizing its input and output to prevent a malicious attacker from exploiting any weaknesses.

 

Related Articles:

Resources:

picCheck out Tripwire SecureScan™, a free, cloud-based vulnerability management service  for up to 100 Internet Protocol (IP) addresses on internal networks. This new tool makes vulnerability management easily accessible to small and medium-sized businesses that may not have the resources for enterprise-grade security technology – and it detects the Heartbleed and Shellshock vulnerability.

picThe Executive’s Guide to the Top 20 Critical Security Controls Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].

Hacking Point of Sale
  • Coyote

    I would like to extend his warning a bit. Perhaps it is because I dislike how it is hard to find a website that does not refer to another site for a script (or some other object) which then referst to another site which.. indeed in a nested fashion (perhaps taking the prize for the highest number of nested loops in source – albeit web source – code known to mankind)… and therefore relying on multiple sites on different networks, perhaps in a different part of the world, for one a single website, maybe even a website that is a single host (as in: one server only). Or maybe it is just I have long thought of this. I don't think it is too relevant though. The more references there are the more chance of something going wrong (is a chain) and that might just be debugging something (I won't elaborate here as it will detract from my point but consider that time wasted is a burden too). I just don't understand why webmasters (those who have the ability, i.e., not using some host that doesn't allow it or makes it difficult to manage) cannot download the scripts they use and refer to it locally. It would have other benefits too. Alas…

    Still, I'm not at all surprised with this warning: any time you have user input you have serious risks. Stack smashing comes to mind, one of many very old attack types. I want to lastly remark on one more thing – and this is the most important bit, perhaps the only important bit, of my response:

    One of the problems that Javed identified was that the developers of WYSIWYG editors think it is the responsibility of those developing the website or back-end server-side systems to perform the sanitization.

    Javed’s solution is to develop a so-called “Unbreakable sanitizer/filter” that does the tricky job of making sure content entered into WYSIWYG editors is safe – and cannot be used to exploit an XSS vulnerability."

    Unfortunately developers (well, many) are lazy and many are also ignorant of the risks. They don't exactly teach secure programming (and if some do they surely need to do a better job which will be quite a feat exactly because there's so many things to consider!). The lazy part is the worst – they place the blame elsewhere, they simply do it to be paid (or some other self-serving reason). As for me, I use mod_security2 (among other kinds of filters!) but in general I have exhaustive (but absolutely NOT enough – there cannot be enough!) filters in place for all services (web is but one service and ALL need filtering/safety mechanisms/…). But the reason for things like mod_security2 is obvious: the same reason for this article.

  • i want to ask about this statement, " If your company has a website, or relies upon a web application, that you think might be at risk be sure to take a long hard look at it and ensure that you are properly sanitizing its input and output to prevent a malicious attacker from exploiting any weaknesses."

    can you explain detailing ,"sanitizing" ?