Rate Limit Bypass

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

Rate limit bypass techniques

Exploring Similar Endpoints

標的となるエンドポイントのバリエーション（例: /api/v3/sign-up、/Sing-up、/SignUp、/singup、/api/v1/sign-up、/api/sign-up など）に対して、brute force attacks を試みるべきです。

Incorporating Blank Characters in Code or Parameters

コードやパラメータに %00、%0d%0a、%0d、%0a、%09、%0C、%20 のような空バイトを挿入することは有効な手法です。例えば、パラメータを code=1234%0a のように調整すると、メールアドレスに改行文字を追加するなど入力のバリエーションで試行回数の制限を回避できる場合があります。

Manipulating IP Origin via Headers

送信元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からのリクエストをシミュレートできます。

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

他のヘッダーの変更

user-agent や cookies のような他のリクエストヘッダーを変更することを推奨します。これらはリクエストパターンの識別や追跡に使われる可能性があるため、ヘッダーを変更することでリクエスターの活動の認識や追跡を防げます。

API Gatewayの挙動を利用する

一部の API Gateway はエンドポイントとパラメータの組み合わせに基づいてレート制限を適用するように設定されています。パラメータ値を変えたり、意味のないパラメータをリクエストに追加することで、ゲートウェイのレート制限ロジックを回避し、各リクエストを一意に見せることができます。例えば /resetpwd?someparam=1。

各試行前にアカウントへログインする

各試行、または各試行セットの前にアカウントへログインすると、レートリミットのカウンターがリセットされることがあります。これはログイン機能のテスト時に特に有用です。Burp Suite のようなツールで Pitchfork attack を利用し、数回ごとに認証情報をローテーションさせ、follow redirects を有効にしておくことで、レートリミットのカウンターを効果的に再起動できます。

プロキシネットワークの利用

リクエストを複数の IP アドレスに分散させるためにプロキシのネットワークを展開することで、IP ベースのレート制限を効果的に回避できます。トラフィックをさまざまなプロキシ経由でルーティングすることで、各リクエストが異なる送信元から来ているように見せ、レート制限の効果を薄めます。

攻撃を別のアカウントやセッションに分散する

ターゲットシステムがアカウント毎やセッション毎にレート制限を適用している場合、攻撃やテストを複数のアカウントやセッションに分散させることで検知を回避しやすくなります。この方法は複数の ID やセッショントークンを管理する必要がありますが、許容される制限内に負荷を配分するのに効果的です。

試し続ける

レート制限が存在していても、正しい OTP を送信したときにレスポンスが異なるかどうかを確認すべきです。In this post、バグハンターは、20 回の失敗後に 401 を返してレート制限が発動しても、正しいものを送った場合は 200 が返ってきたことを発見しています。

HTTP/2 multiplexing & request pipelining の悪用 (2023-2025)

Modern rate–limiter implementations frequently count TCP connections (or even individual HTTP/1.1 requests) instead of the number of HTTP/2 streams a connection contains. When the same TLS connection is reused, an attacker can open hundreds of parallel streams, each carrying a separate request, while the gateway only deducts one request from the quota.

# 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 を保護していない場合、path confusion と HTTP/2 の multiplexing を組み合わせることで、極めて 高速な OTP や credential brute-forcing が可能になります。

🐾 Tip: PortSwigger’s Turbo Intruder は HTTP/2 をサポートしており、maxConcurrentConnections と requestsPerConnection を調整してこの攻撃を自動化できます。

GraphQL の aliases と batched operations

GraphQL では、クライアントが aliases をプレフィックスとして付けることで、単一のリクエストで論理的に独立した複数の queries や mutations を送信できます。サーバーは各 alias を実行する一方で、rate-limiter がしばしば one 件のリクエストしかカウントしないため、これは login や password-reset のスロットリングを回避する信頼できるバイパスです。

mutation bruteForceOTP {
a: verify(code:"111111") { token }
b: verify(code:"222222") { token }
c: verify(code:"333333") { token }
# … add up to dozens of aliases …
}

レスポンスを確認すると、ちょうど1つのaliasは正しいコードが当たったときに200 OKを返し、他はrate-limitedされます。

この手法はPortSwiggerの研究「GraphQL batching & aliases」で2023年に注目され、最近の多くのbug-bounty payoutsに関与しています。

batch or bulk REST endpoints の悪用

一部のAPIは、/v2/batch のようなhelper endpointsを公開したり、request bodyでarray of objectsを受け入れたりします。もしlimiterがlegacy endpointsの前にのみ配置されている場合、複数の操作を1つのbulk requestにまとめることで保護を完全に回避してしまう可能性があります。

[
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"123"}},
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"456"}}
]

sliding-window のタイミング

古典的な token-bucket や leaky-bucket limiter は固定の時間境界（例えば毎分）で リセットされます。ウィンドウが既知の場合（例: X-RateLimit-Reset: 27 のようなエラーメッセージから）、bucket がリセットされる 直前に 許可されている最大数のリクエストを送信し、すぐにもう一度フルバーストを送信します。

|<-- 60 s window ‑->|<-- 60 s window ‑->|
######                 ######

この単純な最適化により、他の bypass technique に手を加えずにスループットを2倍以上にできます。

ハンドシェイク後に WebSockets / gRPC streaming へアップグレード

多くの edge rate-limiters は initial HTTP request のみを検査する。接続が WebSocket (HTTP 101) または gRPC bidirectional streaming にアップグレードされると、その後のメッセージはもはや個別の HTTP リクエストではないため、request-per-second counters を回避することが多い。Cloudflare のドキュメントでも、初回のアップグレードリクエストのみが WAF/レート制限ルールの対象であり、その後に送信されるフレームは不透明であると記載されている。

実践的なワークフロー:

# Flood 1,000 OTP guesses through a single WebSocket connection
seq -w 000000 000999 | websocat -n ws://target.tld/api/verify-ws

# gRPC streaming: send multiple Verify requests in one stream
grpcurl -d @ -plaintext target.tld:50051 service.VerifyOTP/Stream <<'EOF'
{ "code": "111111" }
{ "code": "222222" }
{ "code": "333333" }
EOF

もし login/OTP エンドポイントが HTTP と WebSocket/gRPC の両方のバリアントを公開している場合、まずアップグレードされたチャネルを確立し、その単一の接続内でコードを連続送信してリクエストごとのスロットリングを回避します。

CDN PoP‑sharded counters の悪用

一部の CDNs はレート制限カウンターをグローバルではなくデータセンター/PoP ごとにシャードします。Cloudflare はカウンターがデータセンター間で共有されないことを明示しています。リクエストを多地域のイグレスノード（residential proxy pools、anycast VPNs、または異なる大陸にピン留めした cloud VMs）経由でルーティングすることで、許容スループットを乗算できます：各 PoP が同じキーに対して独立したバケットを維持するためです。

Quick and dirty layout using open proxies (example with proxychains + a country‑rotating list):

for p in $(cat proxies.txt); do
HTTPS_PROXY=$p curl -s -X POST https://target/api/login -d @payload.json &
done
wait

limiter key がアカウント単位（per-account）になっていないことを確認する。そうなっている場合は user IDs / session tokens もローテーションすること。

ツール

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: header randomisation、chunked word-lists、round-robin proxy rotation をサポートする fuzzing ツール。
  • https://github.com/ustayready/fireprox: 使い捨ての AWS API Gateway エンドポイントを自動で作成し、各リクエストが異なる IP アドレスから発信されるようにする — IP-based throttling を回避するのに最適。
  • Burp Suite – IPRotate + extension: SOCKS/HTTP proxies（または AWS API Gateway）のプールを使用し、Intruder および Turbo Intruder 攻撃中に送信元 IP を透過的にローテーションする。
  • Turbo Intruder (BApp): HTTP/2 の multiplexing をサポートする高性能な attack engine。requestsPerConnection を 100–1000 に調整すると、数百のリクエストを単一のコネクションにまとめられる。

参考

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする