國外安全公司發(fā)現(xiàn)了來自Google機器人的SQL注入攻擊，迫使他們應急的時候設置策略對Google的IP進行屏蔽。

有件事情我們需要留意的是，幾乎所有的云防火墻的規(guī)則都會對搜索引擎機器人設置白名單。

目前來說我們的生活還是很幸福的，但當你發(fā)現(xiàn)一個合法的搜索引擎機器人被用來攻擊你的網(wǎng)站，你還睡得安穩(wěn)嗎?

這是幾天前我們一個客戶的網(wǎng)站所發(fā)生的實實在在的案例，我們開始對Google機器人的IP進行屏蔽，根據(jù)抓到的請求可以判斷它做的是SQL注入攻擊。你沒聽錯，對!Google機器人在對你們做SQL注入!

請求

我們的發(fā)現(xiàn)始于Google機器人的IP地址被SQL注入防護策略屏蔽，各位看官看以下日志(打了點碼)：

66.249.66.138 - - [05/Nov/2013:00:28:40 -0500] "GET /url.php?variable=")%20declare%20@q%
20varchar(8000(%20select%20@q%20=%200x527%20exec(@q)%20-- HTTP/1.1" 403 4439 "-" 
"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

我們的第一反應是覺得這是個偽造的機器人，但當我們檢查IP地址來源是卻發(fā)現(xiàn)這是實實在在的google機器人!

$ host 66.249.66.138
138.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-138.googlebot.com.
NetRange: 66.249.64.0 - 66.249.95.255
CIDR: 66.249.64.0/19
OriginAS:
NetName: GOOGLE

進一步調查顯示其它相似的請求簽名都是來自于Google的IP地址。

到底咋回事?

其實Google并不是真有興趣要黑我們，它是真的愛我們。

場景是這樣的：

Google機器人正在網(wǎng)站A收集信息，網(wǎng)站A內嵌入了對目標網(wǎng)站B的SQL注入請求鏈接，Google機器人順著鏈接訪問網(wǎng)站B，就無意中開始對網(wǎng)站B執(zhí)行了SQL注入攻擊。

看到這里大家應該懂了吧?

利用機器人做攻擊?

我們假設有個黑客叫小明。小明每天花很多時間在找web漏洞，所以小明也發(fā)現(xiàn)了一堆的漏洞站。而他也很清楚明白，他必須要掩飾他的行為。

而一個安全人員最普遍的方法都是分析日志。小明也知道這點，所以他現(xiàn)在可能有一個B網(wǎng)站的漏洞，比如SQL注入或者RFI。

于是小明到自己的網(wǎng)站A上面，寫下這些EXP，讓爬蟲來爬……

這種類似場景其實很容易想象吧?

我們已經(jīng)就這個問題聯(lián)系谷歌了。對于爬蟲，我們不能僅僅只是做白名單，而應該在這前面先對請求做檢測!

原文地址：http://blog.sucuri.net/2013/11/google-bots-doing-sql-injection-attacks.html