mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
118 lines
9.9 KiB
Markdown
118 lines
9.9 KiB
Markdown
# レート制限バイパス
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
## レート制限バイパス技術
|
||
|
||
### 類似エンドポイントの探索
|
||
|
||
ターゲットエンドポイントのバリエーションに対してブルートフォース攻撃を試みるべきです。例えば、`/api/v3/sign-up`の代替として、`/Sing-up`、`/SignUp`、`/singup`、`/api/v1/sign-up`、`/api/sign-up`などがあります。
|
||
|
||
### コードやパラメータに空白文字を組み込む
|
||
|
||
`%00`、`%0d%0a`、`%0d`、`%0a`、`%09`、`%0C`、`%20`のような空白バイトをコードやパラメータに挿入することは有効な戦略です。例えば、パラメータを`code=1234%0a`に調整することで、入力のバリエーションを通じて試行を拡張でき、メールアドレスに改行文字を追加して試行制限を回避することができます。
|
||
|
||
### ヘッダーを介してIP起源を操作する
|
||
|
||
ヘッダーを変更して認識されるIP起源を変えることで、IPベースのレート制限を回避するのに役立ちます。`X-Originating-IP`、`X-Forwarded-For`、`X-Remote-IP`、`X-Remote-Addr`、`X-Client-IP`、`X-Host`、`X-Forwared-Host`などのヘッダーを調整し、`X-Forwarded-For`の複数のインスタンスを使用することで、異なるIPからのリクエストをシミュレートできます。
|
||
```bash
|
||
X-Originating-IP: 127.0.0.1
|
||
X-Forwarded-For: 127.0.0.1
|
||
X-Remote-IP: 127.0.0.1
|
||
X-Remote-Addr: 127.0.0.1
|
||
X-Client-IP: 127.0.0.1
|
||
X-Host: 127.0.0.1
|
||
X-Forwared-Host: 127.0.0.1
|
||
|
||
# Double X-Forwarded-For header example
|
||
X-Forwarded-For:
|
||
X-Forwarded-For: 127.0.0.1
|
||
```
|
||
### 他のヘッダーの変更
|
||
|
||
ユーザーエージェントやクッキーなどの他のリクエストヘッダーを変更することが推奨されます。これらはリクエストパターンを特定し追跡するためにも使用される可能性があります。これらのヘッダーを変更することで、リクエスターの活動の認識と追跡を防ぐことができます。
|
||
|
||
### APIゲートウェイの動作を利用する
|
||
|
||
一部のAPIゲートウェイは、エンドポイントとパラメータの組み合わせに基づいてレート制限を適用するように設定されています。パラメータの値を変えたり、重要でないパラメータをリクエストに追加することで、ゲートウェイのレート制限ロジックを回避し、各リクエストをユニークに見せることが可能です。例えば `/resetpwd?someparam=1`。
|
||
|
||
### 各試行の前にアカウントにログインする
|
||
|
||
各試行の前、または試行のセットごとにアカウントにログインすることで、レート制限カウンターをリセットできる場合があります。これは特にログイン機能をテストする際に便利です。Burp Suiteのようなツールでピッチフォーク攻撃を利用し、数回の試行ごとに資格情報を回転させ、リダイレクトをマークすることで、レート制限カウンターを効果的に再起動できます。
|
||
|
||
### プロキシネットワークの利用
|
||
|
||
複数のIPアドレスにリクエストを分散させるためにプロキシのネットワークを展開することで、IPベースのレート制限を効果的に回避できます。さまざまなプロキシを通じてトラフィックをルーティングすることで、各リクエストは異なるソースから発信されているように見え、レート制限の効果を薄めます。
|
||
|
||
### 異なるアカウントやセッションに攻撃を分散させる
|
||
|
||
ターゲットシステムがアカウントまたはセッションごとにレート制限を適用する場合、攻撃やテストを複数のアカウントやセッションに分散させることで、検出を回避するのに役立ちます。このアプローチは複数のアイデンティティやセッショントークンを管理する必要がありますが、許容範囲内に負荷を分散させることができます。
|
||
|
||
### 続けて試す
|
||
|
||
レート制限が存在していても、有効なOTPが送信されたときに応答が異なるかどうかを確認することをお勧めします。[**この投稿**](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732)では、バグハンターが20回の不成功な試行の後にレート制限がトリガーされ、401で応答された場合でも、有効なものが送信されたときには200の応答が受信されたことを発見しました。
|
||
|
||
---
|
||
|
||
### HTTP/2のマルチプレクシングとリクエストパイプライニングの悪用 (2023-2025)
|
||
|
||
現代のレートリミッターの実装は、接続に含まれる**TCP接続**（または個々のHTTP/1.1リクエスト）を数えることが多く、接続が持つ*HTTP/2ストリームの数*を数えることはありません。同じTLS接続が再利用されると、攻撃者は数百の並行ストリームを開くことができ、それぞれが別々のリクエストを運びますが、ゲートウェイは*1つ*のリクエストのみをクォータから差し引きます。
|
||
```bash
|
||
# Send 100 POST requests in a single HTTP/2 connection with curl
|
||
seq 1 100 | xargs -I@ -P0 curl -k --http2-prior-knowledge -X POST \
|
||
-H "Content-Type: application/json" \
|
||
-d '{"code":"@"}' https://target/api/v2/verify &>/dev/null
|
||
```
|
||
もしリミッターが `/verify` のみを保護し、`/api/v2/verify` を保護していない場合、**パス混乱** と HTTP/2 マルチプレクシングを組み合わせて、*非常に* 高速な OTP または認証情報のブルートフォースを行うことができます。
|
||
|
||
> 🐾 **ヒント:** PortSwigger の [Turbo Intruder](https://portswigger.net/research/turbo-intruder) は HTTP/2 をサポートしており、`maxConcurrentConnections` と `requestsPerConnection` を微調整してこの攻撃を自動化できます。
|
||
|
||
### GraphQL エイリアスとバッチ処理
|
||
|
||
GraphQL は、クライアントが **複数の論理的に独立したクエリまたはミューテーションを単一のリクエストで送信する** ことを可能にし、それらを *エイリアス* で接頭辞を付けます。サーバーはすべてのエイリアスを実行しますが、レートリミッターはしばしば *1* 回のリクエストのみをカウントするため、これはログインやパスワードリセットのスロットリングを回避するための信頼できる方法です。
|
||
```graphql
|
||
mutation bruteForceOTP {
|
||
a: verify(code:"111111") { token }
|
||
b: verify(code:"222222") { token }
|
||
c: verify(code:"333333") { token }
|
||
# … add up to dozens of aliases …
|
||
}
|
||
```
|
||
正しいコードがヒットしたとき、正確に1つのエイリアスが200 OKを返し、他はレート制限されます。
|
||
|
||
この技術は、2023年にPortSwiggerの「GraphQLバッチ処理とエイリアス」に関する研究によって普及し、多くの最近のバグバウンティの支払いに寄与しています。
|
||
|
||
### *バッチ*または*バルク* RESTエンドポイントの悪用
|
||
|
||
一部のAPIは、`/v2/batch`のようなヘルパーエンドポイントを公開したり、リクエストボディに**オブジェクトの配列**を受け入れたりします。制限が*レガシー*エンドポイントの前にのみ配置されている場合、複数の操作を単一のバルクリクエスト内にラップすることで、保護を完全に回避できる可能性があります。
|
||
```json
|
||
[
|
||
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"123"}},
|
||
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"456"}}
|
||
]
|
||
```
|
||
### スライディングウィンドウのタイミング
|
||
|
||
クラシックなトークンバケットまたはリーキーバケットリミッターは、固定の時間境界で*リセット*されます（例えば、毎分）。ウィンドウが知られている場合（例えば、`X-RateLimit-Reset: 27`のようなエラーメッセージを通じて）、バケットがリセットされる**直前に**許可された最大数のリクエストを発火し、その後すぐに別のフルバーストを発火します。
|
||
```
|
||
|<-- 60 s window ‑->|<-- 60 s window ‑->|
|
||
###### ######
|
||
```
|
||
このシンプルな最適化により、他のバイパステクニックに触れることなく、スループットを2倍以上に増やすことができます。
|
||
|
||
---
|
||
|
||
## ツール
|
||
|
||
- [**https://github.com/Hashtag-AMIN/hashtag-fuzz**](https://github.com/Hashtag-AMIN/hashtag-fuzz): ヘッダーのランダム化、チャンク化された単語リスト、ラウンドロビンプロキシの回転をサポートするファジングツール。
|
||
- [**https://github.com/ustayready/fireprox**](https://github.com/ustayready/fireprox): すべてのリクエストが異なるIPアドレスから発信されるように、使い捨てのAWS API Gatewayエンドポイントを自動的に作成します - IPベースのスロットリングを打破するのに最適です。
|
||
- **Burp Suite – IPRotate + 拡張機能**: *Intruder*および*Turbo Intruder*攻撃中に、ソースIPを透過的に回転させるためにSOCKS/HTTPプロキシ（またはAWS API Gateway）のプールを使用します。
|
||
- **Turbo Intruder (BApp)**: HTTP/2のマルチプレクシングをサポートする高性能攻撃エンジン; `requestsPerConnection`を100-1000に調整して、数百のリクエストを単一の接続にまとめます。
|
||
|
||
## 参考文献
|
||
|
||
- PortSwigger Research – “GraphQLエイリアスを使用したレート制限のバイパス” (2023) <https://portswigger.net/research/graphql-authorization-bypass>
|
||
- PortSwigger Research – “HTTP/2: 続編は常に悪化する” (セクション *接続ベースのスロットリング*) (2024) <https://portswigger.net/research/http2>
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|