10 ms·

Django does this.

abeld 15y ago
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.
- AndyKelley 15y ago
  > How exactly? Everything is escaped by default, and you have to explicitly request for your content to be unescaped.
  - wisty 15y ago
    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-cookies-httponly.html 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("<","<")' (escaping by default). 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.
    - Pewpewarrows 15y ago
      Handling user-submitted image tags is (in my opinion) way outside the scope of the framework. Which tags and attributes to whitelist, or whether to use html markup at all compared to a different language like markdown, is very project dependent. If you have to, just install BeautifulSoup or any of the other great libraries that have cropped up in the last year or so to handle the sanitizing. 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.
    - jwpeddle 15y ago
      CSRF in on by default. Cookies could be more secure, and it's being worked on. Django is moving to PBKDF2 (there's no pure python bcrypt lib). There's not really opportunity to do anything interesting with slugs. 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.
pavpanchekha 15y ago
No. Django solves the 90% problem, which is usually a fine approach but will llikely lead to security vulnerabilities down the line. I'll refer to something I wrote last time I had this argument: http://pavpanchekha.com/programming/injection.html http://pavpanchekha.com/programming/injection.html.
- dmm 15y ago
  You should replace your '<' with '&lt' if you're going to claim your page is xhtml.
  - pavpanchekha 15y ago
    Thanks. Pages are compiled with org-mode, I'll report a bug.
    - dmm 15y ago
      I love org-mode.
- orclev 15y ago
  Nice article. In response to the last part I can think of a way to achieve the sort of smart escaping via template you talk about using Haskell and Hamlet (among other templating systems used by yesod). I believe, although I can't absolutely confirm that Hamlet already performs context appropriate escaping, based mostly on the type signatures and the names of a few of the functions.
  - gregwebs 15y ago
    Yes, Hamlet does context specific escaping. It will handle all the examples given, except you can't mix your javascript in with your html (which is generally good advice anyways). I disagree with the articles premise that injection is always a display issue. In the [Yesod web framework](http://www.yesodweb.com http://www.yesodweb.com) which uses Hamlet, we sanitize, not strip html by default before it is ever put in the database. The more you can make injection not a display issue, the better- you just have to know your options.

Django does this.

abeld 15y ago

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.

AndyKelley 15y ago
> How exactly? Everything is escaped by default, and you have to explicitly request for your content to be unescaped.
- wisty 15y ago
  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-cookies-httponly.html 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("<","<")' (escaping by default). 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.
  - Pewpewarrows 15y ago
    Handling user-submitted image tags is (in my opinion) way outside the scope of the framework. Which tags and attributes to whitelist, or whether to use html markup at all compared to a different language like markdown, is very project dependent. If you have to, just install BeautifulSoup or any of the other great libraries that have cropped up in the last year or so to handle the sanitizing. 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.
  - jwpeddle 15y ago
    CSRF in on by default. Cookies could be more secure, and it's being worked on. Django is moving to PBKDF2 (there's no pure python bcrypt lib). There's not really opportunity to do anything interesting with slugs. 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.

pavpanchekha 15y ago

No. Django solves the 90% problem, which is usually a fine approach but will llikely lead to security vulnerabilities down the line. I'll refer to something I wrote last time I had this argument: http://pavpanchekha.com/programming/injection.html http://pavpanchekha.com/programming/injection.html.

dmm 15y ago
You should replace your '<' with '&lt' if you're going to claim your page is xhtml.
- pavpanchekha 15y ago
  Thanks. Pages are compiled with org-mode, I'll report a bug.
  - dmm 15y ago
    I love org-mode.
orclev 15y ago
Nice article. In response to the last part I can think of a way to achieve the sort of smart escaping via template you talk about using Haskell and Hamlet (among other templating systems used by yesod). I believe, although I can't absolutely confirm that Hamlet already performs context appropriate escaping, based mostly on the type signatures and the names of a few of the functions.
- gregwebs 15y ago
  Yes, Hamlet does context specific escaping. It will handle all the examples given, except you can't mix your javascript in with your html (which is generally good advice anyways). I disagree with the articles premise that injection is always a display issue. In the [Yesod web framework](http://www.yesodweb.com http://www.yesodweb.com) which uses Hamlet, we sanitize, not strip html by default before it is ever put in the database. The more you can make injection not a display issue, the better- you just have to know your options.