Comments on: How addons.mozilla.org defends against XSS attacks

By: Ennuyer.net » Blog Archive » 2009-03-19- Today’s Ruby/Rails Reading

Ennuyer.net » Blog Archive » 2009-03-19- Today’s Ruby/Rails Reading — Sat, 21 Mar 2009 20:47:15 +0000

[...] All Night Diner : How addons.mozilla.org defends against XSS attacks [...]

By: Wait till I come! » Blog Archive » TTMMHTM: Guardian getting enabled by design,interview,open hack day,bash magic,and XSS filters

Wed, 18 Mar 2009 20:41:44 +0000

[...] If you ever wondered how addons.mozilla.org battles XSS attacks, here’s how [...]

By: Bryan Migliorisi

Bryan Migliorisi — Wed, 18 Mar 2009 16:30:43 +0000

Oops, I posted the link to HTML Purified, a Wordpress plugin for sanitizing comments.

The HTML Purifier can be found @ http://htmlpurifier.org/

By: Bryan Migliorisi

Bryan Migliorisi — Wed, 18 Mar 2009 16:28:54 +0000

Check out HTML purifier @ http://urbangiraffe.com/plugins/html-purified/

It is a php solution that uses whitelists, is recursive, and checks attributes as well as tags. I have never used HTML purifier, but I recently wrote a Java class for doing this exact thing for our web application and it has passed every test I’ve thrown at it thus far. It seems to be a pretty good solution.

By: Jones

Jones — Fri, 13 Mar 2009 11:10:32 +0000

what about cookies and http headers and post? seems an architectural weekness to check this on other places in your app. the best thing would be to check ALL input channels in ONE file and with the same expressions, not clutter it over different files. Also tighten your app to only let ALL input channels through ONE special file, where no side-effects can occur. Also, of course, WHITELIST and not BLACKLIST.
I checked cakephp and it seems one of the weeker frameworks considering security architecture – it leaves certain important steps to the user, that means the framework does NOT make things more secure for you but you have to think yourself – besides having a lot of development goodness from a security pov the question arises “so wtf is the framework good for then?”. Also the AUTH and especially the ACL system is not integrated into he backend but users have to configure and built it itself – it shows that most people do not understand how to do it and open new security holes. As we have seen in the recent past even mature cake devs are not able to implement secure auth themaselves – how could users, if documentation is extremely vague?
cake is a great tool for rapid dev – but it is contraproductive in security as it A) not gives you security for your apps out-of-the-box and B) complicates the way you might be used to secure your site because it injects another level of abstraction. A framework with these weeknesses in security can only be used by extremely experienced developers which are used to study forign code – you will have to study cake very deeply to make a secure site. Of course, if you are that experienced, you will already have your own framework that might be much more accurate and adopts common anti-xss measures to the max.
I predict: many many middle- to low-skilled php developers, mostly typically “designers with some web skillz” will adopt cakephp as a “cool framework” without even knowing anything about its inner workings – and they will produce the next big wave of insecure php applications. That is why a framework MUST be secure out-of-.the-box – every action that might endanger your site must be safe by default and an experienced developer *might* disable this behaviour if she knows what she is doing, not the other way around.

By: AD7six

AD7six — Thu, 12 Mar 2009 08:54:29 +0000

Hi Wil,

Interesting stuff.

Would it be easier/simpler/the same (or is there an additional advantage?) to drop the iconv call and add this to the preg_replace

“/\x00-\x1f/” => ”
( OR “/\x{0000}-\x{002f}/” => ” )

I ask primarily because this is what I do, and want to know if I’m missing out/opening things up ( ).

Cheers,

Andy

By: Garibaldo Persisto

Garibaldo Persisto — Tue, 10 Mar 2009 14:59:27 +0000

would you like to speak out a little bit about what you are expectin the combination of the first two regexes to do? and how did you test, if your expectations are met? Thanks!
Otherwise still very confusing, that a framework like cakephp does still not give you xss protection right out of tthe box.

By: CakePHP Digest #9 - The One Where I Steal Everyone’s Ideas | PseudoCoder.com

Tue, 10 Mar 2009 04:00:57 +0000

[...] You can’t get away from the XSS. @brian_dailey pointed out this article about how addons.mozilla.org combats XSS attacks. [...]

By: Fernando Hartmann

Fernando Hartmann — Tue, 03 Mar 2009 14:25:49 +0000

Good post, I will suggest you, to transform this code in a separated library/project, so all of us can use your skills in our projects.

By: Ian Thomas (thelem)

Ian Thomas (thelem) — Tue, 24 Feb 2009 00:17:51 +0000

Good post. I generally just use htmlspecialchars at the moment, but will consider adding a similar function to our codebase.

I think its worth pointing out more clearly exactly where the sanitise function is run. Lots of developers know that they need to run strings through functions like this to be safe, but they don’t really understand what they are doing so just run the strings through these functions wherever they see the string and remember to do it. That leads to some strings being sanitised multiple times, and others not to be sanitised at all.

It can be tempting just to sanitise everything on it’s way in – once it is in your system it is trusted data (think PHP’s Magic Quotes). But how do you sanitise it? SQL escaping? HTML escaping?

I like to think of it as converting a string from it’s original format, as supplied by the user, to a particular format for how I want to use it. If I want use the string in a PostgreSQL query, then I convert it to PostgreSQL by running it through pg_escape_string. If I want to use it on a web page, then I convert it to HTML by running it through htmlspecialchars (or Wil’s sanitise function). In both cases the end user (querying the database or browsing the web) will see the string in its original format, but the intermediate language (PostgreSQL or HTML) will ignore any special characters.