mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
56 lines
4.7 KiB
Markdown
56 lines
4.7 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の応答が受信されたことを発見しました。
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|