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)에 대해 brute force attacks를 시도해야 합니다. 예를 들어 /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up 등과 같은 대체 경로를 포함해 확인하세요.

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-based rate limiting을 회피하는 데 도움이 될 수 있습니다. 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 gateways는 endpoint와 parameters의 조합을 기준으로 rate limiting을 적용하도록 구성되어 있습니다. parameter 값을 변경하거나 의미 없는 parameters를 요청에 추가하면 gateway의 rate-limiting 로직을 우회하여 각 요청이 고유한 것처럼 보이게 만들 수 있습니다. 예: /resetpwd?someparam=1.

각 시도 전에 계정에 로그인

각 시도 또는 일정 시도 집합 전에 계정에 로그인하면 rate limit 카운터를 초기화할 수 있습니다. 이는 로그인 기능을 테스트할 때 특히 유용합니다. Burp Suite와 같은 도구에서 Pitchfork attack을 사용해 몇 번의 시도마다 자격증명을 교체하고 follow redirects를 활성화하면 rate limit 카운터를 효과적으로 재시작할 수 있습니다.

Proxy 네트워크 활용

요청을 여러 IP 주소에 분산시키기 위해 proxies 네트워크를 배치하면 IP 기반 rate limits를 효과적으로 우회할 수 있습니다. 트래픽을 다양한 proxies를 통해 라우팅하면 각 요청이 서로 다른 출처에서 온 것처럼 보이므로 rate limit의 효과가 희석됩니다.

공격을 여러 계정/세션으로 분산

대상 시스템이 계정별 또는 세션별로 rate limits를 적용한다면, 공격이나 테스트를 여러 accounts나 sessions에 분산하면 탐지를 피하는 데 도움이 됩니다. 이 방법은 여러 신원이나 session tokens를 관리해야 하지만, 허용 한도 내에서 부하를 효과적으로 분산할 수 있습니다.

계속 시도하기

rate limit가 존재하더라도, 유효한 OTP를 보냈을 때 응답이 달라지는지 확인해야 합니다. this post에서 버그 헌터는 20번의 실패한 시도 후 rate limit가 트리거되어 401로 응답하더라도, 유효한 OTP를 보냈을 때는 200 응답을 받았다는 사실을 발견했습니다.

HTTP/2 multiplexing & request pipelining 악용 (2023-2025)

최신 rate–limiter 구현은 종종 연결이 포함하는 number of HTTP/2 streams 대신 TCP connections(또는 개별 HTTP/1.1 requests조차)를 계산합니다. 동일한 TLS connection이 재사용될 때, 공격자는 수백 개의 병렬 streams를 열어 각기 별도의 request를 전송할 수 있고, 그 동안 gateway는 쿼터에서 하나의 request만 차감할 수 있습니다.

# 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

If the limiter protects only /verify but not /api/v2/verify, you can also combine path confusion with HTTP/2 multiplexing for extremely high-speed OTP or credential brute-forcing.

🐾 팁: PortSwigger’s Turbo Intruder supports HTTP/2 and lets you fine-tune maxConcurrentConnections and requestsPerConnection to automate this attack.

GraphQL aliases & batched operations

GraphQL은 클라이언트가 aliases를 접두사로 붙여 한 요청으로 여러 개의 논리적으로 독립된 queries 또는 mutations를 전송할 수 있게 합니다. 서버는 각 alias를 실행하지만 rate-limiter가 종종 한 번의 요청만 카운트하기 때문에, 이는 login 또는 password-reset throttling을 우회하는 신뢰할 수 있는 방법입니다.

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

응답을 보면: 정확한 code가 맞을 때 정확히 하나의 alias만 200 OK를 반환하고, 나머지는 rate-limited 됩니다.

이 기법은 PortSwigger’s의 연구 “GraphQL batching & aliases”(2023)에 의해 대중화되었고, 최근 많은 bug-bounty 보상 지급의 원인이 되었습니다.

Abuse of batch or bulk REST endpoints

일부 API는 /v2/batch와 같은 helper endpoints를 제공하거나 요청 본문에서 array of objects를 허용합니다. Limiter가 legacy endpoints 앞에만 배치되어 있다면, 여러 작업을 하나의 bulk request로 묶어 보호를 완전히 우회할 수 있습니다.

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

슬라이딩 윈도우 타이밍

고전적인 token-bucket 또는 leaky-bucket limiter는 고정된 시간 경계(예: 매분)에서 재설정됩니다. 윈도우가 알려진 경우(예: X-RateLimit-Reset: 27 같은 오류 메시지를 통해), 버킷이 재설정되기 바로 직전에 허용된 최대 요청 수를 전송한 다음, 즉시 또 한 번 전체 버스트를 전송하세요.

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

이 간단한 최적화는 다른 bypass technique을 건드리지 않고도 처리량을 두 배 이상으로 늘릴 수 있습니다.

핸드셰이크 이후 WebSockets / gRPC streaming으로 업그레이드하기

많은 edge rate-limiters는 초기 HTTP 요청만 검사합니다. 연결이 WebSocket (HTTP 101)이나 gRPC 양방향 streaming으로 업그레이드되면 이후의 메시지는 더 이상 개별 HTTP 요청이 아니어서 초당 요청 카운터(request-per-second counters)를 우회하는 경우가 많습니다. Cloudflare의 문서에도 초기 업그레이드 요청만 WAF/rate-limiting 규칙의 대상이며, 이후에 전송되는 프레임은 내부가 불투명하다고 명시되어 있습니다.

실전 워크플로우:

# 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 endpoint가 HTTP와 WebSocket/gRPC 변형을 모두 제공하면, 먼저 업그레이드된 채널을 수립한 다음 그 단일 연결 내에서 코드를 스프레이하여 요청별 제한을 회피하세요.

CDN PoP‑샤드 카운터 악용

일부 CDN은 전역 공유 대신 데이터 센터/PoP별로 rate-limit 카운터를 샤딩합니다. Cloudflare는 카운터가 데이터 센터 간에 공유되지 않는다고 명시적으로 밝히고 있습니다. 여러 지역의 egress 노드를 통해 요청을 라우팅하면(residential proxy pools, anycast VPNs, or cloud VMs pinned to different continents), 허용 처리량을 곱으로 늘릴 수 있습니다: 각 PoP는 동일한 키에 대해 독립적인 버킷을 유지합니다.

공개 프록시를 사용한 간단한 구성(예: proxychains + 국가‑회전 목록):

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는 계정별이 아니어야 합니다; 그렇지 않으면 user IDs / session tokens도 회전시키세요.

도구

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: Fuzzing tool로, header randomisation, chunked word-lists 및 round-robin proxy rotation을 지원합니다.
  • 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을 지원하는 고성능 공격 엔진입니다; 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 지원하기