News for hackers. Stuff that matters.

A comment on Break Google. Parent comment

Re:Break Google by nokcha on Thursday September 15, 2011 @10:57PM (#3003012)
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).

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.
[ Parent | on HN ]
Re:Break Google by colanderman on Thursday September 15, 2011 @11:08PM (#3003040)
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.

[ Parent | on HN ]
Re:Break Google by jerf on Thursday September 15, 2011 @11:30PM (#3003085)
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

[ Parent | on HN ]
Re:Break Google by defen on Friday September 16, 2011 @04:18PM (#3006142)
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.
[ Parent | on HN ]
Re:Break Google by Peaker on Friday September 16, 2011 @09:59PM (#3007002)
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.

[ Parent | on HN ]
Re:Break Google by MostAwesomeDude on Friday September 16, 2011 @08:01PM (#3006782)
twisted.web.template is a great example: http://twistedmatrix.com/documents/current/web/howto/twisted...
[ Parent | on HN ]
Re:Break Google by pavpanchekha on Thursday September 15, 2011 @11:49PM (#3003130)
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.
[ Parent | on HN ]