1

I'm having an exercise to patch an older version of my work from university's e-class. It's written in PHP and requires version 5.3.27. One of the things I want to patch is to prevent XSS. The site uses an old editor (xinha) which supports HTML input without any validation, so XSS is extremely easy to do.

I am not allowed to change the editor so I intend to change the server side validation before using/storing the user input to block event functions (like onerror, onmouseover etc.) and JavaScript. After quite some researches I didn't find any (foolproof) way to filter out JavaScript from HTML. Blocking HTML special characters wont work for me because it will break the HTML tags. Any ideas?

  • There are many XSS Cheatsheets (including one from OWASP) that provide methods to do what you're asking. There is no "foolproof" way to do it, that's why people use script-blockers. – schroeder Apr 16 '17 at 11:28
  • 1
    Which programming language or web platform are you using? – Sjoerd Apr 16 '17 at 11:39
  • I have read many of them already but nothing seemed to help me without breaking the html. Except from htmlpurifier which i also dont think im allowed to use. Do you have any suggestions? Either where to search or what to search for. – George Sp Apr 16 '17 at 11:46
  • @Sjoerd it uses php and only supports 5.3.27 and mysql 4.1.22. It also requires short_open_tag, register_globals and magic_quotes_gpc to be on – George Sp Apr 16 '17 at 11:59
  • 2
    There are several tools and libraries which help you to sanitize html. But this looks for me more like a programming question (off-topic, also the programming language is unknown) or a question for a tool or library (off-topic too, also environment unknown). – Steffen Ullrich Apr 16 '17 at 15:47
1

Filtering out JavaScript from HTML is a very complicated thing to do, especially if you cant restrict the allowed tags and attributes to a small set (or, preferably, none). To get this right is suprisingly complicated and there are many pitfalls. One mistake is all it takes to be vulnerable.

So don't go about this on your own. Use an existing, tried and tested library. For PHP HTML Purifier is a popular one, but I am sure there are more options out there.

In addition, you should use a restrictive content security policy if possible. But don't rely on that as your only line of defence.

1

If you must allow HTML, use something tried and tested such as Google Caja to sanitize it before allowing it to output to your page.

Note that all sanitizers will likely have some undiscovered vulnerabilities. e.g. HTML Purifier has had these in the past, and Google Caja has too, therefore this is not a solid solution and you will need to regularly update your chosen library to mitigate this risk.

Rolling your own solution would be fraught with much greater risk. Also make sure you deploy a strong Content Security Policy that prevents unsafe-inline and that you only whitelist sources that will not contain anything that could make your site vulnerable (even Google CDN contains old, vulnerable versions of JQuery):

https://ajax.googleapis.com/ajax/libs/jquery/2.2.4/jquery.min.js
  • A CSP with a reporting URL would have been my first option for protection. Since the OP mentions PHP, strip_tags() would have been number 2 on the list. Using a third party tool in addition to these might help - but not something which validates on the client. – symcbean Apr 18 '17 at 12:37
  • @symcbean strip_tags() won't work against event handlers added to allowable tags (e.g. <img onload="alert(...). It doesn't matter where it validates it, as long as it is on output not on input. That is, as long as the attacker cannot bypass it. – SilverlightFox Apr 18 '17 at 13:40
  • Nor will javascript in a browser - it just cuts down on the noise. The point I was making is that an effective CSP with a reporting URL is the most effective tool, and doesn't increase the attack surface. – symcbean Apr 18 '17 at 15:46
  • Note that the reporting URL is really for debugging, not for security. Any attacker worth their salt will block requests to the reporting URL while testing any exploits. – SilverlightFox Apr 18 '17 at 16:20
  • I'm sure they will block them while testing their exploits - but it would be rather hard for them to block their victim's access after releasing the exploit. That's why the reporting URL is not for debugging but part of the active defences for a site. – symcbean Apr 18 '17 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.