mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
60 lines
5.3 KiB
Markdown
60 lines
5.3 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の応答が受信されることを発見しました。
|
|
|
|
### ツール
|
|
|
|
- [**https://github.com/Hashtag-AMIN/hashtag-fuzz**](https://github.com/Hashtag-AMIN/hashtag-fuzz): hashtag-fuzzは、WAFやCDNをテストおよび回避するために設計されたファジングツールです。ランダムなUser-Agentやヘッダー値、ランダムな遅延、マルチスレッド処理、単語リストの選択的チャンク化、各チャンクのラウンドロビンプロキシ回転などの高度な機能を活用することで、ウェブアプリケーションの脆弱性を特定しようとするセキュリティ専門家にとって堅牢なソリューションを提供します。
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|