On Jun 21, 2006, at 3:31 PM, Jacob Kaplan-Moss wrote:
> [...]
> Another place to start solving the XSS problem is at the input level;
> a policy of "don't trust data from the web" makes a lot more sense to
> me than one of "don't trust the template author".
Modded "+5 Insightful" :) I can attest personally [1] that doing it
the other way around is an invitation to disaster and inherently
insecure code. The last thing Django needs is a reputation for
insecurity and to go down the path of phpBB and mailman et al. Making
it easy to be secure (i.e. secure by default) benefits everyone. I'd
rather have to manually "non-escape" the occasional string than
escape most all of my strings by hand.
> 2. Methods exist somewhere to "translate" untrusted strings into
> "normal" strings given a particular format. Like Simon, I'm not sure
> how to spell this, but I'm sure a good syntax could be found.
Heck, why not Python's own cgi.escape? [2] Seems trusty enough to me,
though I could be wrong because I'm no Python expert. And, of course,
we can always just use a wrapper method to build on cgi.escape to
allow for further escaping/whatever. (Then again, perhaps I
misunderstood what you meant by "translate".)
> [...]
>
> 4. The template engine automatically escapes untrusted strings
> (unless explicitly passed through a ``raw`` filter) -- this protects
> you from errors when echoing back data given from the browser.
+1 Amen!
> 5. If untrusted strings "sneak" all the way down to the database
> layer... well, I'm not sure about this step; potential options are
> (a) automatically escaping before storing in the database, (b)
> raising an exception, or (c) just letting it happen. I think I
> prefer (b).
>
I think a full-on exception might be a bit harsh, but it could be the
best solution. I don't intend to open a can of worms up here, but
what if manage.py offered a "basic security check" function that is
either run only explicitly by the user or as part of some other
function (syncdb etc.) that checks for untrusted strings that are
publicly viewabel and simply lists them as warnings.
> Thoughts?
Given!
-Tyson
[1] Here at work, we have dozens of JSP intranet apss (*shudder*)
that we've had to go through and implement string escaping for
*everything*. Anything that gets displayed that in some way or form
could have possibly been touched by the outside world must be escaped
manually. *barf*
[2] Sample from Wikipedia's excellent XSS article:
>>> import cgi
>>> print "<script>alert('xss');</script>"
<script>alert('xss');</script>
>>> print cgi.escape("<script>alert('xss');</script>");
<script>alert('xss');</script>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~----------~----~----~----~------~----~------~--~---
