I bet Google knows about this and its when they do bug triage its so low priority that it just hasn't been fixed yet.
Break Google
31–40 of 92 posts
Re: Break Google
#32Earlier quoted context omitted.
Hmm, anybody have an idea as to why mine's different? http://i.imgur.com/OrqtK.png
You loaded the page directly. It only seems to happen if autosearch was involved. Loading http://www.google.com/search?q=$ { does what you see, but entering ${ in to the search box and pressing enter does what everyone else sees. edit: compare your clean human generated address bar to the other screenshot's messy software generated one.
Ahh, makes sense. Thanks for the explanation.
Re: Break Google
#33When 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.
Hrm, but is $ a metacharacter in that language?
Re: Break Google
#34Earlier quoted context omitted.
Hmm, anybody have an idea as to why mine's different? http://i.imgur.com/OrqtK.png
You loaded the page directly. It only seems to happen if autosearch was involved. Loading http://www.google.com/search?q=$ { does what you see, but entering ${ in to the search box and pressing enter does what everyone else sees. edit: compare your clean human generated address bar to the other screenshot's messy software generated one.
It's still broken, even if it looks different
Re: Break Google
#35Oh, 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).
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))
...
Re: Break Google
#36Oh, 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).
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 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.
Re: Break Google
#37Tip to the poster, and to anyone: Google (and Facebook, and others) have bug bounty programs. You can get paid tens to thousands of dollars if you report vulns to the vendor first.
Pretty low bounty.
The base reward for qualifying bugs is $500. If the rewards panel finds a particular bug to be severe or unusually clever, rewards of up to $3,133.7 may be issued.
http://googleonlinesecurity.blogspot.com/2010/11/rewarding-w...
Re: Break Google
#38And i thought that this was one of the most sanitized input field in the internet.
Let's seen how long it takes to google deploy a fix on their search.
Re: Break Google
#39Tip to the poster, and to anyone: Google (and Facebook, and others) have bug bounty programs. You can get paid tens to thousands of dollars if you report vulns to the vendor first.
Pretty low bounty. The base reward for qualifying bugs is $500. If the rewards panel finds a particular bug to be severe or unusually clever, rewards of up to $3,133.7 may be issued. http://googleonlinesecurity.blogspot.com/2010/11/rewarding-w...
For random XSS-style things on web pages, that's a high bounty.
The crazy lucrative bugs you may have heard of tend to be drive-by remote code execution in popular clientsides (like IE or Flash), and the stories about valuations tend to be apocryphal.
Re: Break Google
#40Oh, 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).
Django does this.