Google的FeedFetcher爬蟲會將spreadsheet的=image(“l(fā)ink”)中的任意鏈接緩存。
例如：
如果我們將=image(“http://upload.chinaz.com/2015/0630/1435626856276.jpg”)輸入到任意一個Google spreadsheet中，Google就會“派出”FeedFetcher爬蟲去抓取這個圖片并保存到緩存中以將其顯示出來。
但是，我們可以為文件名附加上隨機參數(shù)，使FeedFetcher多次抓取同一文件。也就是說，如果一個網(wǎng)站有一個10MB的文件，要是將以下列表輸入到Google spreadsheet中，那么Google的爬蟲就會抓取該文件1000次。
=image("http://targetname/file.pdf?r=0")=image("http://targetname/file.pdf?r=1")=image("http://targetname/file.pdf?r=2")=image("http://targetname/file.pdf?r=3")...=image("http://targetname/file.pdf?r=1000")
附加上隨機參數(shù)后，每個鏈接都被看作是不同的鏈接，因此Google爬蟲會去抓取多次，使網(wǎng)站產(chǎn)生大量出站流量。所以任何人只需使用瀏覽器并打開一些標簽，就可以向web服務(wù)器發(fā)動巨大流量HTTP GET洪水攻擊。
但是這種攻擊使攻擊者根本不需要有多大的帶寬，只需要將“圖像”地址輸入進spreadsheet，Google就會從服務(wù)器上抓取這個10MB的數(shù)據(jù)，但是因為地址指向一個PDF文件（非圖像文件），攻擊者從Google得到的反饋為N/A。很明顯這種類型的流量可以被放大多倍，引起的后果很可能是災(zāi)難性的。
只需要使用一臺筆記本，打開幾個web標簽頁，僅僅拷貝一些指向10MB文件的鏈接，Google去抓取同一文件的流量就超過了700Mbps。而這種600-700Mbps的抓取流量大概只持續(xù)了30-45分鐘，我就把服務(wù)器關(guān)閉了。如果沒算錯的話，45分鐘內(nèi)大概走了240GB的流量。
我和我的小伙伴被這么高的出站流量驚呆了。如果文件再大一點的話，我想其出站流量可以輕易達到Gpbs級，而且進站流量也能達到50-100Mbps。可以想象如果多個攻擊者同時用這種方法攻擊某個網(wǎng)站的話，流量能有多少了。同時由于Google用會多個IP地址進行抓取，所以也很難阻止這種類型的GET洪水攻擊，而且很容易將攻擊持續(xù)數(shù)個小時，因為這種攻擊實在是太容易實施了。
發(fā)現(xiàn)這個bug后，我開始搜索由其產(chǎn)生的真實案例，還真發(fā)現(xiàn)了兩例：
第一起攻擊案例解釋了博主如何不小心攻擊了自己，結(jié)果收到了巨款流量賬單。另一篇文章《利用Spreadsheet作為DDoS武器》描述了另一個類似攻擊，但指出攻擊者必須先抓取整個網(wǎng)站并用多個帳戶將鏈接保存在spreadsheet中。
不過奇怪的是沒有人嘗試用附加隨機請求變量的方法。盡管只是目標網(wǎng)站的同一個文件，但通過這種添加隨機請求變量的方法是可以對同一文件請求成千上萬次的，后果還是挺嚇人的，而且實施過程很容易，任何人只需要動動手指頭拷貝一些鏈接就可以做到。
我昨天將這個bug提交給了Google，今天得到了他們的反饋，表示這不屬于安全漏洞，認為這是一個暴力拒絕服務(wù)攻擊，不在bug獎金范圍中。
也許他們事前就知道這個問題，并且認為這不是bug？
不過即使拿不到獎金，我仍希望他們會修復(fù)這個問題，由于實施門檻低，任何人都可以利用Google爬蟲發(fā)動這種攻擊。有一種簡單的修復(fù)方法，就是Google只抓取沒有請求參數(shù)的鏈接。希望Google早日修復(fù)這個bug，使站長免受其帶來的威脅。
