たとえば、表のセルの1つに数式を挿入した場合
GoogleはFeedFetcherスパイダーを送信してこの画像をダウンロードし、テーブルにさらに表示するためにキャッシュします。=image("http://example.com/image.jpg")
ただし、画像URLにランダムパラメーターを追加すると、FeedFetcherはそのたびに再度ダウンロードします。 たとえば、被害者のサイトに10 MBのPDFファイルがあるとします。 そのようなリストをテーブルに挿入すると、Google Spiderは同じファイルを1000回ダウンロードします！
=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=4") ... =image("http://targetname/file.pdf?r=1000")
これはすべて、一部のサイト所有者のトラフィック制限の枯渇につながる可能性があります。 1つのタブを開いたブラウザーのみを使用するユーザーは、どのWebサーバーでも大規模なHTTP GET FLOOD攻撃を仕掛けることができます。
攻撃者は高速チャネルさえ持っている必要はありません。 数式はPDFファイルへのリンクを使用しているため（つまり、テーブルに表示される可能性のある画像へのリンクではないため）、攻撃者はGoogleサーバーからの応答でN / Aのみを受け取ります。 これにより、攻撃を何回も簡単に増やすことができます[DNSおよびNTP増幅のアナログ-約。 翻訳者] 、これは深刻な脅威をもたらします。
複数のタブが開いた1台のラップトップを使用して、リンクのリストをそれぞれ10 MBのファイルにコピーアンドペーストするだけで、Google Spiderはこのファイルを700 Mbps以上の速度でダウンロードできます。 私の場合、これはサーバーをノックアウトするまで30〜45分間続きました。 すべてを正しく計算すると、45分で約240GBのトラフィックがかかりました。
発信トラフィックの量を見て驚いた。 もう少し、発信トラフィックは1 Gb / s、着信50-100 Mbit / sになると思います。 何人かの攻撃者がこの方法を使用するとどうなるか想像できます。 Google Spiderは複数のIPアドレスを使用します。User-Agentは常に同じですが、攻撃によって被害者が驚いた場合、Webサーバー設定の編集は遅すぎる可能性があります。 その使いやすさにより、攻撃は数時間続くことがあります。
このバグが発見されたとき、私はそれを使用してインシデントをグーグルで調べ始め、2つ見つけました：
• ブロガーが偶然自分を攻撃し、交通費の巨額を受け取った方法を説明する記事。 [ ハブレの翻訳 -約。 翻訳者] 。
• 別の記事では、Googleスプレッドシートを使用した同様の攻撃について説明していますが、最初に、著者はサイト上のすべてのファイルへのリンクを解析し、複数のアカウントを使用してこのリストを攻撃します。
リクエストにランダムなパラメーターを追加しようと誰も推測しなかったことは、やや奇妙です。 サイトにファイルが1つしかない場合でも、ランダムパラメータを追加すると、このサイトに何千ものリクエストを行うことができます。 実際、これは少し怖いです。 開いているブラウザのタブに複数のリンクを貼り付けるだけでは、これは起こりません。
昨日、このバグの説明をGoogleに送信し、これは脆弱性ではなく、Bug Bountyプログラムを通過しないという回答を受け取りました。 おそらく彼らはそれを事前に知っていて、実際にはそれをバグとは考えていないのでしょうか？
しかし、私は彼らがこの問題を修正することを願っています。 誰もがGoogle Spiderで非常に多くの問題を発生させることができるのは少し面倒です。 簡単な修正方法は、URLの追加パラメーターをスキップしてファイルをダウンロードすることです[私の意見では、これは非常に悪い修正です。 帯域幅を制限するか、単位時間あたりの要求とトラフィックの数を制限すると同時に、特定のサイズを超えるファイルをダウンロードしないようにする価値があります。 翻訳者] 。