Skip to content

How Google Had Me Mistaken for a Bot

As trusted as Google is, and as infallible as it may sometimes seem, sometimes mistakes are made by Google’s services. In fact, a rather amusing error appeared in Google News recently. When Russian troops entered the former Soviet republic of Georgia, a story about it on Google News included a map that indicated that these Russian troops were actually in the American state of Georgia, and were located just west of Savannah and southeast of Atlanta. Although the error may have been corrected, it was not corrected before it was noticed by at least a few individuals, as you can see if you view this story about this error. There are times such as these that it is apparent that Google’s services need to have improvements made to their ability to analyze data to determine the context of data. And recently, when I was using Google’s search service, I found that it made the mistake of indicating that I was not a human.

In last fortnight’s entry here, I wrote about performing and preventing SQL injection attacks. After writing about that, I considered following up on that entry by writing about these attacks in greater depth. I thought of writing more about everything that one would perform in the process leading up to the SQL injection attack, rather than simply the SQL injection itself. So I decided to gain some practical experience with what may be involved in performing such attacks.

A step that is often performed when hacking is that of looking for potential targets that might have some sort of vulnerability. This activity is one that tends to have the word “war” prefixed to it, as phrases such as “wardialing”, “wardriving” and even “warflying” are often used to describe variations of this activity. And to look for websites that have login forms (through which SQL injection attacks can be attempted) Google can be used. To list websites that have login forms, one can enter a search query such as “inurl:login.php” into Google. This works because pages with login forms often have “login.php” or “login.asp” in their URLs. After I used this method for finding pages that have login forms, many results were returned. However, many of the sites returned in these results may not have had SQL injection vulnerabilities. So I then thought of a way of making it more likely that search results would contain pages that have these vulnerabilities.

The idea that I had for increasing the probability of finding sites with such vulnerabilities was based on this assumption: Websites that have these vulnerabilities are unlikely to be listed in the first pages of Google’s search results. Websites that would be more likely to be ranked before others when Google searches are performed may be more likely to have the measures needed to prevent SQL injection attacks implemented. Therefore, after displaying the first few pages of results after submitting the search query, I decided to bring up the tenth page of results, and then I brought up the nineteenth page of results. Then I received an error saying that my search query looked “similar to automated requests from a computer virus or spyware application.” Google thought that I was a bot. And so if you click here to perform a Google search similar to the one that I performed, you can convince Google that you are a bot as well.

I recall hearing about others finding that something like this happened to them. However, I had never experienced anything like this myself. I was not trying to pass or fail a reverse Turing test, and Google gave me a result that was unexpected and, of course, inaccurate. Some may find it interesting that I am writing something that may seem critical of Google near Google’s tenth anniversary. However, I did use Google in trying to find websites with a certain characteristic. And that is one of many tasks that I would always use Google to perform.