

Break Google - volksman
http://www.mahdiyusuf.com/post/10246392773/break-google-search

======
cfinke
When 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>)

~~~
jcampbell1
I think google search uses this templating language:

<http://code.google.com/p/google-ctemplate/>

It makes sense that the ${ could cause problems.

~~~
tptacek
Hrm, but is $ a metacharacter in that language?

~~~
RyanKearney
Hrm, did you click the link?

~~~
irahul
Most likely he did. Did you?

If you did click and skim the page at 1000000000 words/sec, those `$` over
there are for USD, and not part of templating system.

------
aristus
Tip 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.

~~~
johnbatch
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...](http://googleonlinesecurity.blogspot.com/2010/11/rewarding-
web-application-security.html)

~~~
tptacek
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.

------
snowboardbum1
For 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/>

~~~
karlzt
and it doesn't exist if you search it from the url bar or the searchbar (with
google as search engine) of firefox.

------
pavpanchekha
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
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.

~~~
colanderman
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.

~~~
defen
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
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.

------
gburt
If this is a templating engine type thing, you should be able to do something
like

${KEYWORD}${

If you can figure out what "KEYWORD" is for a given template tag as well. I
tried links and a few others, but none that I can identify: it does still
reproduce the bug though.

------
exogen
Seems likely that it's due to a lack of escaping in a custom templating layer.
I wonder if it could be used to perform a XSS attack?

~~~
ahlatimer
Unlikely. You'd have to get someone else to run the same query.

~~~
exogen
...which you can do simply by posting a link anywhere.

Edit: I guess it would be more helpful to explain why for those not familiar
with XSS. If all it takes it a specially crafted URL to your site to exploit
it, your site is toast. The security model of the web assumes that people can
open even the shadiest of links without negative consequences. I could have
obscured the URL with a shortener and named the link "Cutest cat pic ever!" I
could have hosted a page on a totally separate domain and put the crafted URL
in a hidden iframe. All I have to do is send document.cookie over to my server
and now I control your account.

~~~
ahlatimer
My mistake. I thought it didn't work if you linked to it directly. It turns
out the bug just manifests itself differently if you do that.

------
michaelpaul
And 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.

------
epaga
Interestingly enough, the https version of Google doesn't have this bug.

<https://encrypted.google.com/#q=$>{

looks fine, but

[http://www.google.com/search?sourceid=chrome&ie=UTF-8...](http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=%24){

doesn't.

~~~
dchest
The first one is broken for me too (in a different way, though).

------
alorres
Also works if you use the html code: "&#36;&#123;" It returns the symbol
instead of the search query.

------
tathagatadg
They fixed it .. <http://google.com/#q=$>{

~~~
redwood
funny tho that at this point such a query would not return the discussion
about this flaw :)

------
esrauch
Anyone have an explanation for this? Looks like its messing up the CSS for the
top link nav.

~~~
raldi
I'm not seeing it. Can you post a screenshot?

~~~
dangrossman
<http://i.imgur.com/3UuEZ.png>

~~~
vorbby
Hmm, anybody have an idea as to why mine's different?

<http://i.imgur.com/OrqtK.png>

~~~
gburt
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.

~~~
hammock
It's still broken, even if it looks different

------
bengl
Note: this also works: <http://www.google.com/#q=$%7B>

------
jdandrea
The Google Search Appliance, with roots in Google proper, generates XML
results, which are then (normally) transformed via XSLT. (I'm looking at you,
XPath.)

[http://mikewest.org/2007/06/escaping-curly-braces-in-xslt-
at...](http://mikewest.org/2007/06/escaping-curly-braces-in-xslt-attributes)

I s'pose attributes don't enter into it, but still, I wonder if the XSLT pass
(if any) has anything to do with this?

------
IanMikutel
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.

------
simplycomplex
This 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...](http://www.rajeeshcv.com/2010/07/have-you-seen-google-search-
crashing/)

------
nhebb
On a related note, searches for many symbols do not product results. Searching
for '&' will bring up results for ampersand, but most others that map well to
words do not, e.g. $ => dollar, % => percent, etc.

------
baddox
> _Shortest way to produce issue is here —<http://google.com/#q=$>{ _

Making it an actual hyperlink would've been a bit shorter.

~~~
SwellJoe
I would have been suspicious of a hyperlink in this context...since this is
potentially discussing a XSS vulnerability on Google (not necessarily, but
maybe).

------
deleo
Looks like the syntax of Google's CTemplate someone posted today:
<http://code.google.com/p/google-ctemplate/>

------
sullof
This is from yesterday:
<http://twitter.com/#!/passpack/status/114181283097214977>

------
mikecane
I tried it in my Search box at WordPress.com blog and it has no effect.

------
zeynalov
try to search this and see real break 9999999..99999999999999999999999

~~~
kaerast
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.

~~~
zeynalov
thanks for info

------
henriquepss
That's 'cause the money ($) is the key (}). Oh, you're welcome.

------
karlzt
the bug exists only by searching on the google homepage, searching it on the
searchbar of the browser doesn't happen.

~~~
pyre
Breaks for me in either case, just in different ways (an auto-search link
breaks the toolbar, while the other one doesn't even display the toolbar).

------
dadoner
it doesn't break on google.co.ma

------
skeptical
Everyone seems to avoid to mention the obvious. This breaks the page layout
only, not really a critical issue concerning google's integrity/security.

Still, this obviously doesn't look good. Above anything else google has
excelled on being simple and reliable. All this javascript goodness added
recently might be a step in the wrong direction. If stuff like this starts to
happen every now and then, google's reputation might be at stake.

------
speleding
If your templating language is going to use a magic character it would seem
useful to pick something less common than $. There are several odd characters
on my keyboard (§`~±|¤) and if you are willing to use the ALT key there are
really obscure characters that you can safely filter from the input instead of
going through the trouble of escaping them. Filtering is so much more
efficient/easier/safer than escaping.

Imagine how much easier life would be if in HTML we only had to filter for §
instead of escape every <, > and ".

~~~
dramaticus3
~ is not unusual on the internet, it is used for home directory webspace

<http://www.proweb.co.uk/~matt> for instance

~~~
dramaticus3
That's my homepage. It's been a long time since I read it.

Reading it now as a treatise from my younger self, though I didn't write it, I
realise that spirit is lost. For a while it was "our" place but now we have to
return to the underground.

~~~
dramaticus3
I changed it

<http://www.proweb.co.uk/~matt/oldworld.html>

