Slashdot Mirror
Google 302 Exploit Knocks Sites Out
clsc writes "The exploit: Redirect via 302 to another page of your choice, then watch as the URL of your redirect script replaces the URL of that carefully selected page in Google's search results. Once this happens, feel free to redirect any visitor that is not Googlebot to any other page of your choice. Also applies to other search engines as well (not Yahoo! though)."
Web wide malware. The return of Goatse cannot be far behind... Pun intended.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
#15) Optional: For mischievous webmasters only: For any other visitor than "Googlebot", make the redirect script point to any other page free of choice.
heh. tubgirl abounds!
1. post how to generate more traffic to one's website by exploiting a flow in google on /.
...
2. show a "random" ad (336px by 280 px) promoting 'google adsense' clearly stating "how to turn your website into a revenue generator in minutes" at said post.
3. $$$
SELL SELL SELL SHORT!!!!
boy, sending me to the wrong page is such a scary and horrible thing to do. Luckily my browser came equipped with the special "back button" anti-malware plugin.
"Weapons should be hardy rather than decorative" - Miyamoto Musashi
I think that goes for OS's too
Insert MS blame here
sure. Do some 302 redirect-statistic-hack. Make money. Cheat your customers. No it's no excuse that other ones are doing it as well, bad attitude.
We are the Borg of LiarMarketing. Resistance is futile, human.
come on - get a life, be straight.
"First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
Oracle 9iAS and 10gAS are VERY heavy on the 302 redirects (as a way to moderate traffic using mod_oc4j).
/foo, you'd see a redirect from http://www.example.com/foo to http://www.example.com/foo/, but I can see this product borking up search results as its use becomes pervasive in the enterprise.
Most of the redirects are innocuous, for example with an application whose context-root is
Since the product can't be changed, I'd probably change Google's behavior.
Three Step Plan:
1. Take over the world.
2. Get a lot of cookies.
3. Eat the cookies.
It's an exploit if you can't prevent someone from misusing 302, or to filter out malicious uses of 302 from legitimate ones.
You see? You see? Your stupid minds! Stupid! Stupid!
Hey look! Someone forgot to RTFA!
You use 302 to hijack someone else's page in Google's search results. Your bogus ad infested page shows up instead of the actual content the user was searching for (and thought they were going to see), while the real website that you hijacked doesn't get any more Google traffic. That's the exploit.
Dumbass.
How is this hijacking? How is this any different from me simply adding the text and title of the other page to my page? Sure, I can change the redirect later, or change it for anyone except for googlebot, but I can do that with the content just as easily (more easily, in fact).
Furthermore, I suspect google has at least a few bots which don't announce themselves as googlebots just to check for such discrepancies.
Seems like all the hackers are struggling now-a-days. There are no "good" exploits coming out anymore. No directory Unicode transversals.. No Code Red, No Nimda. Not even SQL Slammer...
We haven't had a good exploit/0day in how long? Since the Webdav exploit? Or the RPC DCOM? Now we have to use Google, phishing techniques, and URL redirection. We are scraping the bottom of the barrell apparently.
In the article is says:
/. I'm sure that would create attention!
"For this to happen, we need to put some pressure on the search engines."
Such as posting it on
Warning, comments may not have been passed by the sanity department of my brain.
The use of the exploit isn't just to childishly send people to Goatse - it's about money. What happens when you go to your bank's website and get redirected to an identical-looking website that steals your information?
A site registered and hosted using stolen funds from my credit card is still online following phoned and faxed demands for revocation and refund sent to the registrar/host. Can I somehow use this to send an entire domain to a black hole until the hosting/domain are revoked? It wouldn't be hacking, but it would make me feel a lot better to see the scammers knocked offline. If no one can get to them on google, they can't get any scam income. And what are they going to do -- sue me? That just would result in my slapping them with *criminal* charges as well as a motion for dismissal and a countersuit.
i am a soviet space shuttle
In the Google example shown in TFA, its "easy" to spot a hijack by looking at the URL. But if Google or other search engines were to support IDN (Internationalized Domain Names), then it would be even easier for a criminal to hijack a bank's login page with the IDN browser exploit.
Two wrongs don't make a right, but three lefts do.
Sheesh. What a description. Couldn't he just say:
Create page that, when accessed by Googlebot, creates its own HTTP connection to a different, highly ranked page, and returns its contents to the Googlebot, but retuns your contents to everyone else than Googlebot.
Ooops - no 302 needed? Houst^H^HGoogle, we have a problem.
Wow. That's a fun exploit... I can't wait to go tell my boss why our site links to a pron site on google.
All kidding aside this could be a major problem for some of the more controversial websites. Akin to the Googlebombing that was just mentioned yesterday this could be the next major attack scheme on the net. Imagine a pro-life site subverting a pro-choice site, Neo-nazi's subverting a site intended for Jewish children, the US government subverting Al Jazera...
Not a whole lot of fun IMHO. I trust google to return what I search for, if this changes I and a whole lot of other nerds are going to be left wandering aimlessly around the net.
well i guess this could be good news for the blogging google bombers..... http://slashdot.org/article.pl?sid=05/03/15/003522 5&tid=217&tid=1
they might actually get something done about the spam.
The main thread about this on WebMasterWorld is over 500 posts now.. lots of good info there.
This sig all sigs devours
It doesnt replace the URL at all. My reading is that google simply adds a new page in the database for the url you gave it. In this regard, how is this any different to a wget --mirror on the attempted "hijacked" site? Maybe more efficient but the net result is you are just trying to blag google hits of someone else's content.
PageRank _should_ sort this out as I'm sure lots more people will be linking to news.bbc.co.uk than to r.example.tld/foo/rAndoMLettERS (from the example).
Storm in a [child's] teacup.
This means that you can't reliably hijack the page unless you have a higher PR than it. But if you have a higher PR than that page then could just as well copy its content, then wait till you're spidered, then substitute for whatever you want.
In other words, this is nothing more than another way to exploit two existing problems: (a) that you can steal anyone's content on the web (though see this for a way to detect it) and (b) you can cloak your site for the search engines (though I'm sure they notice that too).
In summary, there is nothing new in this whatsoever.
Anyone that wants to steal your traffic can take advantage of this. Nearly all the sites that I have created in the last year have been purposely hijacked by this and don't show up in any Google rankings. I've learned to live with it despite contacting the jerk responsible who pleaded innocent and said he wasn't very technical and didn't know what was going on.
Historically, good content meant good search engine placement. Now that this little trick is being more publicized, it just decreases the amount of time required for someone to hijack your entire site and remove it completely from the search engine results.
I'm a big tall mofo.
Do you mean this is not www.kuro5hin.org ??
BoD
...if I COULD get to the page. But it's being redirected with a 302. ;P
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
I've seen this effects of this first hand and it's a slightly nastier problem than people realise.
It's not uncommon for search engines to penalise sites for duplicate content, i.e. identical content on multiple domains. So with this problem all it takes is a couple of other sites to link to you, completely innocently with a 302, and *bang*, your site disappears down the listings.
I've noticed that a lot of my google searches get redirected to an Ebay search page even though the displayed url in the search results is a non-ebay url. I checked the Google cached result and it was not the same as the re-directed page.
It's very annoying as I haven't been able to figure out what is going on. The same Ebay search results show up under dozens of urls in the Google search results
Windows firewall.
Windows firewall apparently put the rubber on any bugs out there spreading rapidly. Don't lose all hope though there's plenty of viruses that can spread the old fashioned way, through email and MSN. Not even by exploiting vulnerabilities, just by suckering people.
"Visit this URL and download and run this cool file"
I expect a nasty IM virus someday.
There seems to be a lot of confusion as to why exactly this is such a big deal. A lot of people saying there's no problem or that this is nothing... basically just not understanding the issue. Let me explain:
Suppose you have a small business under the domain http://xyz.com/, and search engines bring you a lot of traffic because you rank high for keywords in your market. You have a lot of people out there linking to you, a lot of satisfied customers, good content on your site. You're always in the top 10 somewhere when people search for "xyz widgets".
Well, this issue with Google makes it very easy -- incredibly easy -- for someone to knock your site out of the rankings entirely. And I mean for *everything*, to where searching for your own company name in quotes literally buries you hundreds of pages deep in the results. We're talking sites going from getting 1000 unique hits to 10 overnight.
And here's the kicker: It requires absolutely no technical knowledge, no time investment, and is perfectly legal...
All I have to do is have another domain handy that is roughly as popular as yours. And I make a "links" page, like one of those directory services, that lists your website. But instead of being a normal hyperlink, it's a CGI (or PHP or ASP or whatever) script that generates a 302 redirect to your domain... Now, these are very simple, common scripts. One-liners that you can download from cgiscripts.com and stick on your server. The original intent of these scripts is to track which links are being clicked on your site. But now they've found a new use, because when Google gets that 302, all hell breaks loose.
See, according to the HTTP spec, 302 is a *temporary* redirect, which means Google is supposed to interpret whatever content it finds at the 302 target (your site) as really belonging to the URL of the source (my site). Google is just obeying the spec strictly here, and with devestating results. Why? BECAUSE THE DUPE FILTER NOW KICKS IN! You see, Google has a "dupe filter" that says if the same exact content is found for two unique URLs, then one of the URLs is obliterated in the rankings. Because after all, searchers don't want to be finding the same content over and over. If that happens, they'll start using a different search engine. But Google, sticking strictly to the HTTP spec, doesn't know who the content really belongs to when it gets a 302.
So Google essentially flips a coin. And if it comes up tails, say bye-bye to your domain in the rankings. Your *entire* domain. Because the dupe filter isn't limited to just the page that the 302 is pointing to -- it applies across your entire domain.
These 302 "exit-link-trackers" are all over the web. They've been used by webmasters for years. But it's just recently that Google has started treating 302 this way, so it didn't have any bad effect before. But now it kills you.
The funny thing is, the solution seems pretty simple: Just stop treating 302s this way if they point to a different domain. But for whatever reason Google isn't listening. Hopefully the press that's being generated now will give them the kick in the ass that they need.
I don't get it. This is all just sensationalism to me. If you play with 302 redirects, something bad might happen, but there's no way to predict it (as per the article, it's an arbitrary choice based on pagerank and other internal mechanisms). To me this is just a Google equivalent of terror alert orange.
Well, I knew about the 302 bug (in fact, it's been known for months in professional webmaster circles).. so, I did an allinurl:mydomain.com/mypage.htm search on Google to find the culprit. Low and behold, it was some blog page about one PR below my page with a script that redirected through a 302. The catch was that this redirect script ONLY worked if you clicked on it from the blog itself - if you clicked on it from the Google SERPs you got a 500 server error.. so in effect, Google misidentified the redirect page as my actual page and then subsequently tried to spider it from the URL directly and got a 500 error.. the result being that I was dropped from the index. Was this malicious? Hardly - the webmaster had compiled a small list of cool, useful links - not knowing that his buggy redirector was killing those sites off.
So whaddya do? I tried emailing the webmaster but everything bounced. It looks like he was out of the country. I tried giving Google feedback, but frankly that's just like offering up a prayer to the Great Google God - so I also used the BASE HREF trick mentioned in the article, and after a few days the page came back in the index as normal. So, either that trick worked or the Google God answered my prayers. I'm guessing at the former.
Never email donotemail@WeAreSpammers.com
This "exploit" isn't very interesting and the author really doesn't seem to have a good grasp of the HTTP protocol design, the end-to-end model, or the internet in general.
I'd be very careful before I blindly changed all my redirects to 301s. The semantics behind a 301 and 302 are VERY different and unless you want people to replace the original URI with the target in your 301s, forever, you might be entering a world of hurt.
From RFC 2616 -- HTTP/1.1 :
10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
10.3.3 302 Found
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
This is a common theme in the high-tech world; Joe Hacker figures out a problem and a 'solution'. Problem is, they don't understand all the implications of the solution. That doesn't stop them from yelling loudly about the solution. Without a comprehensive explanation of the impact of the 'solution' you might be just causing yourself harm in other areas down the road.
Education and thorough analysis are always a good idea when you are dealing with complex systems that might have emergent behaviors. This is certainly one of the bigger pet-peeves at the IETF and with the IESG.
as can be seen in this thread on webmasterworld:
I have two sites, one is the main site which we'll call www.widgets.com and one is a site with a catchy name that automatically diverts to www.widget.com, we'll call this site www.widgetscatchy.com.
Kind of confused that www.widgetscatchy.com site had a PR5 so checked the incoming links and for some reason when I check the links to this site is shows www.widgets.com's links instead of it's own. Even when listing the site Google states 'Searched for pages linking to AYdabadfa:www.widgets.com/' instead of 'Searched for pages linking to AY4cSZStU-0J:www.widgetscatchy.com/'
The sites are using the same hosting company but they're both two completely seperate accounts and have completely different content.
Why has Google amalgamated these two sites links? I'm just slightly worried that Googlebot will drop the pair of the sites from the index if it decides that the two sites are the same.
*waves hand*
"This isn't the webpage you are looking for."
A quick search on Google gave me this link:
t ra cker2php_pag_1.htm
http://www.tonyspencer.com/mt/archives/2004/12/
This has clearly been documented before. I'm surprised it has not been fixed after all this time. The slashdot post and the clsc.net page gave me the impression this was something new.
Tired of having search results hijacked to other web portal search engines or what-not, I have pretty much resorted to previewing my search results. I tend to skip over pages that, for one reason or another, do not have a link to the cached page.
To-do List: Receive telemarketing call during a tornado warning. Check.
It would be nice if someone did something like this to the CherryOS "developers".
Easiest way to fix it is to not follow 302's since 302 means "The requested resource resides temporarily under a different URI."
.
I would imagine that this could cause a problem with getting a website into the listing that is in the process of moving, but if Google simply waited until it's an actual 200 status code, then redirections would get ignored (since they're not
From the W3C document:
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
Again, and since even the temporary URI doesn't have to be given, 302's should be ignored. Even 301's and 303's are not acceptable since the new URI doesn't have to be given.
The harder way to fix it is to only accept 3xx response codes that give the new URI in response. Even then, I assume it's possible to still fake a 200 response code if you modify the http daemon, and make a transparent redirection... thus fooling the search engine in every respect.
In my opinion, I don't see a way around it unless you include signature files or such... but even if you used and SSL connection, it's probably still exploitable.
I guess you're damned any way you look at it.
I started writing a spider way back when I first found out about the internet (1995ish) as a learning experience and have continued to tweak it over time, although it is not yet a commercial product.
.html...
.com/index.php
/ecommerce/index.php identifying itself as the true identity of that page. If at some point, you change from php to to the next great scripting language, the change to the base href will pick that up. I would HOPE that the Google duplicate detection considers the BASE URI to be authoritative as long as it matches the domain, and drops all other identical pages.
The problem the spider has to deal with in trying to organize and rank the results is that there is an inherent problem with the way web servers handle default web pages for a domain or a directory:
http://www.xyz.com/ actually pulls up http://www.xyz.com/index.html (because apache or the web server has been told to use index.html if no page component is in the URI) - but there is no requirement to communicate the "index.html" page name to the client, and very few servers actually do that (if they do, you'll see the URL change in the browser)
Some of the incoming links point to just the doemain, other links point to the fully qualified URL. More than likely, your spider will eventually follow both and then receive web pages that are nearly identical.
At some point, xyz.com discovers php (yea!)... but they have traffic and page rank associated with index.html. They put up a 302 redirect to point index.html -> index.php
Or they symlink index.html to index.php and tell php to parse index.html even though the extension is
So from google's perspective:
http://xyz.com/
http://www.xyz.com/
http://xyz.com/index.html
http://www.xyz.com/in dex.php
http://www.xyz.com/index.html
http://xyz
all return identical content and the web has links pointing to every one of those names (and those links almost never go away or are corrected once created). From the Search Engine's perspective, which is the "real" URL/URI for the page?
Google (and the visitor) generally would like the answer to be
http://www.xyz.com/
Using the BASE URL tag tells Google the actual page name and clears up any ambiguity, which is why using one partially fixes the problem in some cases.
<head>...<base href="http://www.xyz.com/index.php"></head>
Now, let's make it uglier:
Ecommerce web site is installed in subdirectory, but wants its main page to be the "default" page for the domain - referral tracking and cookie management depends on this - however the web pages rely on the package existing in a subdirectory of the document root:
Actual URI is http://www.xyz.com/ecommerce/index.php
How do you get to that page as the default without confusing the search engines or losing the referring URL? Possible answers:
1) Use a meta refresh - doing that loses tracking information, as the landing page becomes the referring page. Google will also not be happy as this looks like a doorway page, and the redirect page itself has no real "content" to index
2) Use a 301 redirect - Bzzzzt - wrong answer - if you do this, you'll telling the world that http://www.xyz.com/ no longer exists in all perpetuity.
3) Use a 302 redirect - clears up tha ambiguity, however confusing Page Ranking at least temporarily - since your incoming links mostly point at http://www.xyz.com/, not http://www.xyz.com/ecommerce/index.php
4) Use a Base Ref on
5) Have the web server return a content-location: header. This is similar to the base URL, except it is done at the http level not within the HTTP. content-location: can either be relative to the request or absolute. It isn't authoritative, but could be helpful. In general, a cross-domain content-location header would have to be ignored, otherwise you would have the same exploit... you request
Final 2006 "Proof of Global Warming" US Hurricane Count -> 0