61–70 of 92 posts
Interestingly enough, the https version of Google doesn't have this bug. https://encrypted.google.com/#q=$ { looks fine, but http://www.google.com/search?sourceid=chrome&ie=UTF-8... { doesn't.
Earlier quoted context omitted.
How exactly? Due to django's "we want the templating system be general, to be usable for stuff other than html", it can't provide support for such 'guarantee that the output is well formed / valid / has no injection attack entry points' features.
> How exactly? Everything is escaped by default, and you have to explicitly request for your content to be unescaped.
How do you handle user-submitted image tags? Do you allow rich formatting, and if so, how do you sanitize it? (see http://www.codinghorror.com/blog/2008/08/protecting-your-coo...)
I think that Django uses sha for password hashes. They should use bcrypt, right? Did you turn on XSRF protection (which I think is off by default)? Are cookies secure?
Web security is not as simple as 's.replace("How do you generate slugs? Could someone put something nasty in a pathname or URL?
Django is not secure. You can secure it, with minimal effort, if you keep things radically simple. But you do need to know what can go wrong, so you don't introduce any "features" that are actually "gaping security holes".
Even if you do everything right, it doesn't mean that Django is magically secure no matter what people use if for (obvious, yes, but this is HN and sometimes failing to point out the obvious can get you downvoted). That's why people are objecting.
http://mikewest.org/2007/06/escaping-curly-braces-in-xslt-at...
I s'pose attributes don't enter into it, but still, I wonder if the XSLT pass (if any) has anything to do with this?
Still, this obviously doesn't look good. Above anything else google has excelled on being simple and reliable. All this javascript goodness added recently might be a step in the wrong direction. If stuff like this starts to happen every now and then, google's reputation might be at stake.
Earlier quoted context omitted.
> How exactly? Everything is escaped by default, and you have to explicitly request for your content to be unescaped.
OK, you escape stuff. Great. How do you handle user-submitted image tags? Do you allow rich formatting, and if so, how do you sanitize it? (see http://www.codinghorror.com/blog/2008/08/protecting-your-coo... ) I think that Django uses sha for password hashes. They should use bcrypt, right? Did you turn on XSRF protection (which I think is off by default)? Are cookies secure? Web security is not as simple as 's.replac…
Like any framework, there will always be room to improve security, but it does do very well out of the box. At least it makes you work to expose anything obvious.
Earlier quoted context omitted.
I think google search uses this templating language: http://code.google.com/p/google-ctemplate/ It makes sense that the ${ could cause problems.
Hrm, but is $ a metacharacter in that language?
Earlier quoted context omitted.
> How exactly? Everything is escaped by default, and you have to explicitly request for your content to be unescaped.
OK, you escape stuff. Great. How do you handle user-submitted image tags? Do you allow rich formatting, and if so, how do you sanitize it? (see http://www.codinghorror.com/blog/2008/08/protecting-your-coo... ) I think that Django uses sha for password hashes. They should use bcrypt, right? Did you turn on XSRF protection (which I think is off by default)? Are cookies secure? Web security is not as simple as 's.replac…
Django uses sha for password hashes because until recently there hasn't been a better library to ship with natively across all the platforms that Django supports. If you know you'll only be working on *nix, django-bcrypt can enhance the default password hashing behavior. As other commenters have noted, they're moving to PBKDF2 in the near future as a better included hashing library.
CSRF is on by default. If you need secure cookies and HSTS headers, there's a package that provides them called django-secure, which last I heard is being rolled into Django proper in the near future.
Django prevents path traversal and anything else you can imagine that might be nasty in a URL. The auto slug generation included.
So how exactly is Django not scure again? Where are the "gaping security holes"? Or do you have no idea what you're talking about.