アカウント名:
パスワード:
この攻撃はどうもHTTP/2の単一コネクションで複数のリクエストを並列に行える仕様を攻撃に使った物でリクエストの発行とキャンセルのペアを一つのコネクションに大量に流し込むらしい。# ……それって脆弱性なのか……？仕様では？なので一つのIPコネクションに対して膨大なリクエスト数がある、筈。
しかし、キャンセルされているのでサーバはコンテンツで応答する必要もない。キャンセルされているのにレスポンスの準備を走らせてると負荷になるが、リクエストをキューイングしたりしてれば最初以降はレスポンスを準備する事なくキャンセルできそう。
リクエスト数だと大きいけどコネクションは少ないし、応答もキャンセル効いてれば程々の負荷で済む。対策も増えるだろうしあまり意味のある攻撃ではないかも
リクエストを受け付ける時点である程度の負荷があるので、他の攻撃に対する軽さが問題にならないぐらい大量のリクエストを送りつけるんじゃないですかね。それこそキューから溢れるぐらいとか。
即キャンセルすることでリクエスト数の上限への抵触回避してるって説明があるので、キャンセルをリクエストと同じ優先度で逐次処理してればキューに積んでも即座にキューから消すからキューは伸びない。キューの操作コストはリクエスト＆キャンセル要求電文の生成コストよりは高そうだから、チリ積もで負荷にはなるだろうけど、数字のインパクトが先行しすぎとは思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
理屈と結果 (スコア:0)
この攻撃はどうもHTTP/2の単一コネクションで複数のリクエストを並列に行える仕様を攻撃に使った物で
リクエストの発行とキャンセルのペアを一つのコネクションに大量に流し込むらしい。
# ……それって脆弱性なのか……？仕様では？
なので一つのIPコネクションに対して膨大なリクエスト数がある、筈。
しかし、キャンセルされているのでサーバはコンテンツで応答する必要もない。
キャンセルされているのにレスポンスの準備を走らせてると負荷になるが、
リクエストをキューイングしたりしてれば最初以降はレスポンスを準備する事なくキャンセルできそう。
リクエスト数だと大きいけどコネクションは少ないし、
応答もキャンセル効いてれば程々の負荷で済む。
対策も増えるだろうしあまり意味のある攻撃ではないかも
Re: (スコア:0)
リクエストを受け付ける時点である程度の負荷があるので、他の攻撃に対する軽さが問題にならないぐらい大量のリクエストを送りつけるんじゃないですかね。
それこそキューから溢れるぐらいとか。
Re: (スコア:0)
即キャンセルすることでリクエスト数の上限への抵触回避してるって説明があるので、
キャンセルをリクエストと同じ優先度で逐次処理してれば
キューに積んでも即座にキューから消すからキューは伸びない。
キューの操作コストはリクエスト＆キャンセル要求電文の生成コストよりは高そうだから、
チリ積もで負荷にはなるだろうけど、数字のインパクトが先行しすぎとは思う。