Thanks. Output filtering is definitely a good thing, but I'm more worried about input filtering. If users are allowed to submit HTML that will be displayed to other users, I want to pass the HTML through a strict validator to keep them from posting scripts.
Imagine we have a hypothetical website with a on-site email thing much like MySpace or Flickr. The attack then goes like:
1) Malory, our attacker wants to compromise user Alice's account
2) Malory crafts a message with an embedded script, and uses on-site mail to send it to Alice
3) When alice retrieves the email, the embedded script executes as if it were content originating from the site
4) The script can then inspect Alice's session cookie, and through a AJAX post can send it to Malory.
Jigs's up. Malory has Alice's session cookie and can in theory autheticate as Alice, and retrieve all of her personal information, for identity theft.
The much worse scenario is what happened to myspace. The attack script could propagate through the site's mail system by sending itself to all of Alice's mail contacts (by reading her inbox, looking through a friends list, etc.)
Of course simply stripping all HTML in input data is an OK solution, but more and more people like rich HTML data for certain types of data (mail, profile pages, etc.)
Whenever a user enters data into a site that is displayed to another user, I'd like to be able to pass it thorough a security filter that at least raises the bar for XSS attacks.
Output escaping is also good practice, but the safest way to deal with hostile input is to make sure it isn't hostile *before* it's stored. Otherwise you incur the risk of the data popping out through an unsanitized view. This is especially dangerous for the admin site. Imagine the potential danger of including a </textarea><script>...</script> in certain fields that are displayed to admins ... got r00t? (I'm not sure this specific attack works, its just for illustration).
There's a good lookin' implementation of what I'm talking about here: http://simon.incutio.com/archive/2003/02/23/safeHtmlChecker
Thanks,
~ol
On 11/7/06, James Bennett <[EMAIL PROTECTED]> wrote:
On 11/7/06, Oliver Lavery <[EMAIL PROTECTED]> wrote:
> I was a little disappointed to see that Django doesn't include a safe HTML
> checker / sanitizer. RoR has something along these lines afaik (which is
> very little in this case).
We include the 'escape' and 'striptags' filters, but there is no
"escape everything the framework outputs" setting. There's been
extensive discussion of this on the developer list and thus far
no-one's stepped up with a clean implementation that doesn't get in
the way of some use cases (keep in mind that Django's template system
is expected to be able to produce more than just HTML, and that things
which prevent XSS attacks in HTML can break other output formats).
There are multiple thread on the dev list about escaping; this search
seems to net most of them if you'd like to read up on what's already
been discussed:
http://groups.google.com/group/django-developers/search?group=django-developers&q=escaping&qt_g=1&searchnow=Search+this+group
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
