5 ms·

Oh, cute. Yet another injection flaw in Google. Guys, (and I don't mean Google, I mean all of us), don't fix injection by plugging injection bugs; put togethe

Oh, cute. Yet another injection flaw in Google. Guys, (and I don't mean Google, I mean all of us), don't fix injection by plugging injection bugs; put together some framework that actually avoids all of these problems (or at least doesn't let you add bugs).

nokcha 15y ago
This is actually a hard problem in the general case, and it is an active area of research. One promising approach is static taint analysis, wherein the source code of a web app is analyzed to detect whether "tainted" output is given to a sensitive "sink" without being properly sanitized. See, e.g., Omer Tripp et al., "TAJ: Effective Taint Analysis of Web Applications" (PLDI 2009) (http://www.cs.tau.ac.il/~omertrip/pldi09/paper.pdf http://www.cs.tau.ac.il/~omertrip/pldi09/paper.pdf). As an example of a difficult case, consider the following pseudocode snippet: ... if request['raw']: print("Content-Type:text/plain; charset=utf-8\r\n\r\n") print(doc) else: print("Content-Type:text/html; charset=utf-8\r\n\r\n") print(html_sanitize(doc)) ... In one branch, doc must be HTML-sanitized; in the other branch, it must not.
- colanderman 15y ago
  That's a poor example. I would never send a document as HTML without tags. html_sanitize() should really be generate_html(), which adds structure to the document. What the GP is saying (and I agree with) is that generate_html() should use a library which understands HTML structure and only allows content to be generated using a strict API (no doc+="<foo>bar</foo>" garbage). Such a discipline greatly reduces the chance of injections, to the point where you have to actively write code to create injection points. And it's simple to follow: any time you write HTML, use the library. Taint analysis sounds nice in theory, but you can get the same effect by writing code modularly (i.e. only one small module can actually access the raw output stream) and using libraries to create structured data.
  - jerf 15y ago
    You don't know where "doc" is coming from from a snippet like that. I use logic moderately similar to that for my blog software. If I'm writing the blog post, pretty much pass through what I wrote. If it's a comment (back when I had them), process the heck out of it. The blog post itself is a blob of HTML, basically. I do not currently write my blog posts in a templating language (any more than anyone else does), though Hamlet [1] has me sort of tempted as it is so close to what I write anyhow. [1]: http://www.yesodweb.com/book/templates http://www.yesodweb.com/book/templates
  - defen 15y ago
    It's not a poor example, and it's not about sending the document without tags. It's about whether special characters should be escaped, and the answer depends on the Content-Type that the client requested.
    - Peaker 15y ago
      A framework could use static types to tag whether it is escaped or not. Then, the framework could map different kinds of requests (e.g: raw content vs. html content) to different types. Then, the only way to convert between the types are functions that do proper escaping.
  - MostAwesomeDude 15y ago
    twisted.web.template is a great example: http://twistedmatrix.com/documents/current/web/howto/twisted-templates.html http://twistedmatrix.com/documents/current/web/howto/twisted...
- pavpanchekha 15y ago
  You're making the same mistake made by people who mistake good static type systems and type inference. Yes, it would be nice to infer the correct escaping function; but forcing people to escape somehow would be sufficient.
AndyKelley 15y ago
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.

nokcha 15y ago

This is actually a hard problem in the general case, and it is an active area of research. One promising approach is static taint analysis, wherein the source code of a web app is analyzed to detect whether "tainted" output is given to a sensitive "sink" without being properly sanitized. See, e.g., Omer Tripp et al., "TAJ: Effective Taint Analysis of Web Applications" (PLDI 2009) (http://www.cs.tau.ac.il/~omertrip/pldi09/paper.pdf http://www.cs.tau.ac.il/~omertrip/pldi09/paper.pdf). As an example of a difficult case, consider the following pseudocode snippet: ... if request['raw']: print("Content-Type:text/plain; charset=utf-8\r\n\r\n") print(doc) else: print("Content-Type:text/html; charset=utf-8\r\n\r\n") print(html_sanitize(doc)) ... In one branch, doc must be HTML-sanitized; in the other branch, it must not.

colanderman 15y ago
That's a poor example. I would never send a document as HTML without tags. html_sanitize() should really be generate_html(), which adds structure to the document. What the GP is saying (and I agree with) is that generate_html() should use a library which understands HTML structure and only allows content to be generated using a strict API (no doc+="<foo>bar</foo>" garbage). Such a discipline greatly reduces the chance of injections, to the point where you have to actively write code to create injection points. And it's simple to follow: any time you write HTML, use the library. Taint analysis sounds nice in theory, but you can get the same effect by writing code modularly (i.e. only one small module can actually access the raw output stream) and using libraries to create structured data.
- jerf 15y ago
  You don't know where "doc" is coming from from a snippet like that. I use logic moderately similar to that for my blog software. If I'm writing the blog post, pretty much pass through what I wrote. If it's a comment (back when I had them), process the heck out of it. The blog post itself is a blob of HTML, basically. I do not currently write my blog posts in a templating language (any more than anyone else does), though Hamlet [1] has me sort of tempted as it is so close to what I write anyhow. [1]: http://www.yesodweb.com/book/templates http://www.yesodweb.com/book/templates
- defen 15y ago
  It's not a poor example, and it's not about sending the document without tags. It's about whether special characters should be escaped, and the answer depends on the Content-Type that the client requested.
  - Peaker 15y ago
    A framework could use static types to tag whether it is escaped or not. Then, the framework could map different kinds of requests (e.g: raw content vs. html content) to different types. Then, the only way to convert between the types are functions that do proper escaping.
- MostAwesomeDude 15y ago
  twisted.web.template is a great example: http://twistedmatrix.com/documents/current/web/howto/twisted-templates.html http://twistedmatrix.com/documents/current/web/howto/twisted...
pavpanchekha 15y ago
You're making the same mistake made by people who mistake good static type systems and type inference. Yes, it would be nice to infer the correct escaping function; but forcing people to escape somehow would be sufficient.

AndyKelley 15y ago

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.