try to search this and see real break 9999999..99999999999999999999999
Break Google
71–80 of 92 posts
Re: Break Google
#72try to search this and see real break 9999999..99999999999999999999999
No, that's designed to break - within that range is a large amount of credit cards numbers, and Google blocks that. The OP however is a genuine bug.
Re: Break Google
#73Earlier quoted context omitted.
Django does this.
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 .
You should replace your '<' with '<' if you're going to claim your page is xhtml.
Re: Break Google
#74Re: Break Google
#75Earlier quoted context omitted.
Django does this.
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 .
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.
Re: Break Google
#76When you search for "${", the page is missing 26 lines of minified JavaScript (lines 9-35 of a non-broken page, at least for me), almost certainly because of a templating bug. These lines, among other things, are responsible for adding the top toolbar to the page. (The missing JS is here: http://pastebin.com/B9cy3T2c )
I think google search uses this templating language: http://code.google.com/p/google-ctemplate/ It makes sense that the ${ could cause problems.
I disagree! It does not make sense that submitting any text via a form input should in any way interfere with a templating engine, in the same way we dont expect to be able to affect a database by entering SQL into a form field.
The fact that Google brings back an empty result set to me indicates the problem is a bit deeper...
Re: Break Google
#77For me just typing ${ breaks the layout. I agree it probably has something to do with a template engine. I know Java EL uses the syntax ${variable_name} and so does Velocity Templates. The bug doesn't exist on https://encrypted.google.com/
and it doesn't exist if you search it from the url bar or the searchbar (with google as search engine) of firefox.
Re: Break Google
#78This looks like a javascript issue but I have seen a server error from google - http://www.rajeeshcv.com/2010/07/have-you-seen-google-search...
Re: Break Google
#79That's 'cause the money ($) is the key (}). Oh, you're welcome.
Re: Break Google
#80Earlier quoted context omitted.
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/…
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+=" bar " garbage). Such a discipline greatly reduces the chance of inje…
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.