💻
Application Security Cheat Sheet
  • Application Security Cheat Sheet
  • Android Application
    • Overview
      • Application Data & Files
      • Application Package
      • Application Sandbox
      • Application Signing
      • Deployment
      • Package Manager
    • Intent Vulnerabilities
      • Deep Linking Vulnerabilities
    • WebView Vulnerabilities
      • WebResourceResponse Vulnerabilities
      • WebSettings Vulnerabilities
  • CI/CD
    • Dependency
      • Dependency Confusion
      • Dependency Hijaking
      • Typosquatting
    • GitHub
      • GitHub Actions
      • Code owners
      • Dependabot
      • Redirect
      • Releases
  • Cloud
    • AWS
      • Amazon API Gateway
      • Amazon Cognito
      • Amazon S3
  • Container
    • Overview
      • Container Basics
      • Docker Engine
    • Escaping
      • CVE List
      • Exposed Docker Socket
      • Excessive Capabilities
      • Host Networking Driver
      • PID Namespace Sharing
      • Sensitive Mounts
    • Container Analysis Tools
  • Framework
    • Spring
      • Overview
      • Mass Assignment
      • Routing Abuse
      • SpEL Injection
      • Spring Boot Actuators
      • Spring Data Redis Insecure Deserialization
      • Spring View Manipulation
    • React
      • Overview
      • Security Issues
  • Linux
    • Overview
      • Philosophy
      • File
      • File Descriptor
      • I/O Redirection
      • Process
      • Inter Process Communication
      • Shell
      • Signals
      • Socket
      • User Space vs Kernel Space
    • Bash Tips
  • iOS Application
    • Overview
      • Application Data & Files
      • Application Package
      • Application Sandbox
      • Application Signing
      • Deployment
    • Getting Started
      • IPA Patching
      • Source Code Patching
      • Testing with Objection
  • Resources
    • Lists
      • Payloads
      • Wordlists
    • Researching
      • Web Application
      • Write-ups
    • Software
      • AWS Tools
      • Azure Tools
      • Component Analysis
      • Docker Analysis
      • Dynamic Analysis
      • Fuzzing
      • GCP Tools
      • Reverse Engineering
      • Static Analysis
      • Vulnerability Scanning
    • Training
      • Secure Development
  • Web Application
    • Abusing HTTP hop-by-hop Request Headers
    • Broken Authentication
      • Two-Factor Authentication Vulnerabilities
    • Command Injection
      • Argument Injection
    • Content Security Policy
    • Cookie Security
      • Cookie Bomb
      • Cookie Jar Overflow
      • Cookie Tossing
    • CORS Misconfiguration
    • File Upload Vulnerabilities
    • GraphQL Vulnerabilities
    • HTML Injection
      • base
      • iframe
      • link
      • meta
      • target attribute
    • HTTP Header Security
    • HTTP Request Smuggling
    • Improper Rate Limits
    • JavaScript Prototype Pollution
    • JSON Web Token Vulnerabilities
    • OAuth 2.0 Vulnerabilities
      • OpenID Connect Vulnerabilities
    • Race Condition
    • Server Side Request Forgery
      • Post Exploitation
    • SVG Abuse
    • Weak Random Generation
    • Web Cache Poisoning
Powered by GitBook
On this page
  • Rate limits overview
  • Bandwidth throttling after reaching a certain rate
  • Changing IP address
  • Override original IP
  • Using proxy or VPN
  • Changing path
  • Extra characters in parameters
  • Multiple values in request
  • Race condition
  • Rate limits after authentication
  • Reset a rate limit
  • Send requests to different instances of an application
  • References
  1. Web Application

Improper Rate Limits

PreviousHTTP Request SmugglingNextJavaScript Prototype Pollution

Last updated 3 years ago

Rate limits overview

A rate limit is used to bandwidth throttling and/or a limit on the number of attempts, for instance, when checking passwords or OTP. If the lack of rate limit, it becomes possible to send an arbitrary number of requests.

If the established restrictions are violated, an application may return 429 Too Many Requests or 200 OK with an error in the response body. However, an application may not change the HTTP code and response body, thus creating the appearance of a lack of rate limit. In some cases you can verify this behavior by entering a valid value, for instance, valid password or OTP, thus simulating the final result of bruteforce.

Bandwidth throttling after reaching a certain rate

Rate limit algorithms can only respond to how many requests were made in a certain period of time. If you try to send requests using n-threads, rate limit algorithm will throttle the bandwidth. To avoid this behavior, you should send requests using a single thread and possibly even with a delay between requests.

Changing IP address

Many rate limit algorithms rely on a client IP address when deciding to block a request. If you change the IP address or make a server think that the request came from another IP, you will successfully bypass this restriction.

Override original IP

If an application relies on the value of HTTP headers to determine an original IP address of a client, you can try to override IP address with the following headers:

For instance, you can add the X-Forwarded-For header to the OTP check request:

POST /api/v1/otp/check HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 9
X-Forwarded-For: <desired-ip>

otp=12345

Using proxy or VPN

You can use a proxy or VPN to change an IP address. To automate the change of IP addresses, use the following methods:

  • A ready-made or self-written script with a large number of proxy servers or VPNs.

If an application is behind a CloudFlare firewall, all requests sent from AWS IPs will be blocked. To avoid this, you need to discover an original IP of an application.

Changing path

Try to change an endpoint path to bypass rate limits. Use different case or add extra symbols, such as %00, %09, %0a, %0c, %20, etc. For instance, if a bare endpoint is /api/v4/endpoint, try the following endpoints:

  • /api/v4/endpoint

  • /api/v4/Endpoint

  • /api/v4/EndPoint

  • /api/v4/endpoint%00

  • /api/v4/%0aendpoint

  • /api/v4/endpoint%09

  • /api/v4/%20endpoint

  • ...

Also, you can try to add extra parameters, for example, /api/v4/endpoint?some_param=1

Extra characters in parameters

Try to add extra symbols, such as %00, %09, %0a, %0c, %20, etc. to params. For instance, if requesting a code to an email have only n tries, use name@website.com%00 after exceeding n attempts, then name@website.com%20, and etc.

Multiple values in request

When brute-force, try passing several values in one request at once, for instance:

{
    "phone": "+17342239011",
    "code": [
        "123456",
        "654321",
        "133713",
        // ...
        "331337"
    ]
}

or

phone=+17342239011&code[]=123456&code[]=654321&...&code[]=331337

An application can correctly process such requests and interpret this as one attempt, which will significantly expand the number of possible attempts.

Race condition

Rate limits after authentication

An application can implement different rate limits for authenticated and unauthenticated users. For instance, after authentication, there may be no rate limits on attempts to change a password or disable two-factor authentication.

Reset a rate limit

An application may incorrectly implement rate limits or have a logical vulnerability that allows a user to reset the limits.

For example, an application may reset limits on attempts to send OTP when you resend a new OTP, so you can reset rate limits before each OTP check attempt and a rate limit will be never reached. Or an application may store the remaining number of attempts in a cookie, and you can reset the limit by spoofing the cookie.

Send requests to different instances of an application

Often, an application backend is deployed on multiple instances that run in parallel. Accordingly, when a client sends a request to the backend, a balancer ties a user's session to a specific instance. This can be accomplished by setting a custom HTTP header or cookie with an instance ID. If rate limit values are not synchronized between instances, you can increase the number of available attempts by sending requests to different instances. In order to find out existing IDs, try to send requests to the backend from different IPs and without the header or cookie. A balancer will assign a random instance and return it in the header or cookie for such requests.

References

. Extension for Burp Suite which uses AWS API Gateway to rotate your IP on every request.

. A Python library to utilize AWS API Gateway's large IP pool as a proxy to generate pseudo-infinite IPs for web scraping and brute forcing.

IPRotate_Burp_Extension
requests-ip-rotator
Two-factor authentication security testing and possible bypasses
Race Conditioncheat-sheets
Logo