# Rate Limit Bypass

{{#include ../banners/hacktricks-training.md}}

## Rate limit bypass techniques

### Exploring Similar Endpoints

대상 엔드포인트의 변형에 대해 무차별 공격을 시도해야 합니다. 예를 들어 `/api/v3/sign-up`와 같은 엔드포인트의 변형으로는 `/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 기반 속도 제한을 피하는 데 도움이 될 수 있습니다. `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
```
### 다른 헤더 변경하기

user-agent 및 쿠키와 같은 다른 요청 헤더를 변경하는 것이 권장됩니다. 이러한 헤더는 요청 패턴을 식별하고 추적하는 데 사용될 수 있습니다. 이러한 헤더를 변경하면 요청자의 활동을 인식하고 추적하는 것을 방지할 수 있습니다.

### API 게이트웨이 동작 활용하기

일부 API 게이트웨이는 엔드포인트와 매개변수의 조합에 따라 속도 제한을 적용하도록 구성되어 있습니다. 매개변수 값을 변경하거나 중요하지 않은 매개변수를 요청에 추가함으로써 게이트웨이의 속도 제한 논리를 우회할 수 있으며, 각 요청이 고유하게 보이도록 만들 수 있습니다. 예를 들어 `/resetpwd?someparam=1`.

### 각 시도 전에 계정에 로그인하기

각 시도 또는 시도 세트 전에 계정에 로그인하면 속도 제한 카운터가 초기화될 수 있습니다. 이는 로그인 기능을 테스트할 때 특히 유용합니다. Burp Suite와 같은 도구에서 Pitchfork 공격을 활용하여 몇 번의 시도마다 자격 증명을 회전하고 리디렉션을 따르도록 표시하면 속도 제한 카운터를 효과적으로 재시작할 수 있습니다.

### 프록시 네트워크 활용하기

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

### 다른 계정이나 세션에 공격 분산하기

대상 시스템이 계정별 또는 세션별로 속도 제한을 적용하는 경우, 여러 계정이나 세션에 공격 또는 테스트를 분산시키면 탐지를 피하는 데 도움이 될 수 있습니다. 이 접근 방식은 여러 신원 또는 세션 토큰을 관리해야 하지만, 허용 가능한 한도 내에서 부하를 효과적으로 분산시킬 수 있습니다.

### 계속 시도하기

속도 제한이 설정되어 있더라도 유효한 OTP가 전송될 때 응답이 다른지 확인해 보아야 합니다. [**이 게시물**](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732)에서 버그 헌터는 20번의 실패한 시도 후 401로 응답하더라도 속도 제한이 발생하더라도 유효한 OTP가 전송되면 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}}