130n@calvinlai.com
  • About Calvin Lai (fkclai)
  • My Work
  • Cyber Security
    • Cyber Security Centre (CSC)
      • Why we need a CSC
      • CSC Team Structure: Roles, Functions, and Tools
        • Key Function & Role
        • Tools & Platforms
        • People
        • Outsource Strategy
      • HRMC Executive Paper
  • Detection and Response
    • Playbook: Threat Prioritization & Automated Response Strategies
      • Scenario: Detecting and Mitigating a Ransomware Attack
      • Scenario: DC Sync Attack Detected and Mitigated
      • Scenario: Pass-the-Hash (PtH) Attack Detected and Contained
      • Scenario: Phishing Campaign with Malware / Credential Theft Detected and Mitigated
  • Application Architecture
    • Comparison of MVC , N-tier and Microservice Architecture
  • Application Security
    • OAuth, SAML, and OpenID Connect: Key Differences and Use Cases
    • Secure Coding Principles
    • HTTP Header Security Principles
    • Mitigating Broken Object Level Authorization (BOLA)
    • Spring Boot Validation
    • Output Encoding in JavaServer Faces (JSF)
    • Session Management Security Issues
    • Common API Security Problems
      • Broken Authentication
      • Excessive Data Exposure
      • Lack of Resources & Rate Limiting
      • Broken Function Level Authorization
      • Unsafe Consumption of APIs
    • JAVA Exception Handling
    • File Upload Validation
    • OAuth 2.0 Security
      • Insecure Storage of Access Tokens
    • Microservice Security
      • Sample Coding Demo
        • Service Implementation
        • Client Interaction
      • Security Solution for Microservices Architecture
    • Modifying and Protecting Java Class Files
      • Modify a Class File Inside a WAR File
      • Direct Bytecode Editing
        • Steps to Directly Edit a Java Class File
          • Update: Java Bytecode Editing Tools
      • Techniques to Protect Java Class Files
        • Runtime Decryption in WebLogic
    • JAVA Program
      • Secure, Concurrent Web Access Using Java and Tor
      • Creating a Maven Java project in Visual Studio Code
  • Exploit/CVE PoC
    • ZeroLogon Exploit
    • Remote Retrieved Chrome saved Encrypted Password
    • Twitter Control an RCE attack
  • Hacking Report (HTB)
    • Hits & Summary
      • Tools & Cheat Sheet
    • Windows Machine
      • Love 10.10.10.239
      • Blackfield 10.10.10.192
      • Remote 10.10.10.180
      • Sauna 10.10.10.175
      • Forest 10.10.10.161
      • Sniper
      • Json
      • Heist
      • Blue
      • Legacy
      • Resolute
      • Cascade
    • Linux Machine
      • Photobomb 10.10.11.182
      • Pandora 10.10.11.136
      • BountyHunter 10.10.11.100
      • CAP 10.10.10.245
      • Spectra 10.10.10.229
      • Ready 10.10.10.220
      • Doctor 10.10.10.209
      • Bucket 10.10.10.212
      • Blunder 10.10.10.191
      • Registry 10.10.10.159
      • Magic
      • Tabby
  • Penetration Testing
    • Web Application PenTest
    • Network/System PenTest
    • Mobile Penetration Test
      • Certificate Pinning
        • Certificate Pinning Bypass (Android)
          • Root a Android Device
          • Setup Proxy Tool - Burp Suite
      • Checklist
  • Threat Intelligence
    • Advanced Persistent Threat (APT) groups
      • North Korean APT Groups
      • Chinese APT Groups
      • Russian APT Groups
      • Other APT
  • Red Team (Windows)
    • 01 Reconnaissance
    • 02 Privileges Escalation
    • 03 Lateral Movement
    • 04 AD Attacks
      • DCSync
    • 05 Bypass-Evasion
    • 06 Kerberos Attack
    • 99 Basic Command
  • Exploitation Guide
    • 01 Reconnaissance
    • 02 Port Enumeration
    • 03 Web Enumeration
    • 04 Windows Enum & Exploit
      • Windows Credential Dumping
        • Credential Dumping: SAM
        • Credential Dumping: DCSync
      • Kerberos Attack
      • RDP
    • 05 File Enumeration
    • 06 Reverse Shell Cheat Sheet
      • Windows Reverse Shell
      • Linux Reverse Shell
    • 07 SQL Injection
    • 08 BruteForce
    • 09 XSS Bypass Checklist
    • 10 Spring Boot
    • 11 WPA
    • 12 Payload list
  • Vuln Hub (Writeup)
    • MrRobot
    • CYBERRY
    • MATRIX 1
    • Node-1
    • DPwwn-1
    • DC7
    • AiWeb-2
    • AiWeb-1
    • BrainPan
  • CTF (Writeup & Tips)
    • CTF Tools & Tips
    • Hacker One
    • CTF Learn
    • P.W.N. University - CTF 2018
    • HITCON
    • Pwnable
      • 01 Start
  • Useful Command/Tools
    • Kali
    • Windows
    • Linux
  • Offensive Security Lab & Exam
    • Lab
    • Tools for an Offensive Certification
      • Strategy for an Offensive Exam Certification
        • CVEs
        • Privilege Escalation
        • Commands
        • Impacket
  • ISO 27001
    • Disclaimer
    • What is ISO 27001
      • Implementation
    • Documentation
    • Common Mistake
    • Q&A
      • Can internal audit to replace the risk assessment
      • Is it sufficient for only the IT department head to support the ISO 27001 program
      • Does the Business Continuity Plan (BCP) and a Disaster Recovery Plan (DRP) are the same?
    • ISO 27001 Controls and Domains
      • 1. Information Security Policies
      • 2. Organization of Information Security
      • 3. Human Resource Security
      • 4. Asset Management
      • 5. Access Control
      • 6. Cryptographic Controls
      • 7. Physical and Environmental Security
      • 8: Operational Security
      • 9. Communications Security
      • 10. System Acquisition, Development, and Maintenance
      • 11. Supplier Relationships
      • 12: Information Security Incident Management
      • 13. Information Security Aspects of Business Continuity Management
      • 14. Compliance
Powered by GitBook
On this page
  • What is Lack of Resources & Rate Limiting?
  • Vulnerable Code and Secure Code Example
  • Attack Scenario
  • Insecure Implementation (Prone to Lack of Resources & Rate Limiting)
  • Attack Payload Example:
  • Secure Implementation (Mitigating Lack of Resources & Rate Limiting)
  • Implementing Rate Limiting: Code Level vs. System Level
  • Code Level Rate Limiting
  • System Level Rate Limiting
  • Which is Better?
  • Key Points for Developers
  • Summary and Key Takeaways
  • Reference Links

Was this helpful?

  1. Application Security
  2. Common API Security Problems

Lack of Resources & Rate Limiting

What is Lack of Resources & Rate Limiting?

Lack of Resources & Rate Limiting occurs when an API does not impose restrictions on the number or frequency of requests from a client. This can lead to several issues, including server overloads, degraded performance, and potential security vulnerabilities.

Maps to OWASP Top 10

This vulnerability is categorized under A04:2021 - Unrestricted Resource Consumption in the OWASP Top 10. It highlights the importance of implementing proper resource management and rate limiting to ensure API security and reliability.

Vulnerable Code and Secure Code Example

Attack Scenario

Imagine an API endpoint designed to fetch user data. Without rate limiting, an attacker can send thousands of requests per second, overwhelming the server and causing it to become unresponsive. This can lead to a Denial of Service (DoS) attack, where legitimate users are unable to access the service.

Insecure Implementation (Prone to Lack of Resources & Rate Limiting)

@RestController
@RequestMapping("/api")
public class UserController {

    @Autowired
    private UserRepository userRepository;

    @GetMapping("/users")
    public List<User> getUsers() {
        // Fetch all users from database
        return userRepository.findAll();
    }
}

Attack Payload Example:

for i in {1..10000}; do
    curl http://localhost:8080/api/users
done

In this case, the server may become overwhelmed by the high volume of requests, leading to performance issues or unresponsiveness.

Secure Implementation (Mitigating Lack of Resources & Rate Limiting)

@RestController
@RequestMapping("/api")
public class UserController {

    @Autowired
    private UserRepository userRepository;

    @GetMapping("/users")
    public ResponseEntity<List<User>> getUsers() {
        // Fetch all users from database
        List<User> users = userRepository.findAll();

        // Implement rate limiting
        if (isRateLimitExceeded()) {
            return new ResponseEntity<>(HttpStatus.TOO_MANY_REQUESTS);
        }

        return new ResponseEntity<>(users, HttpStatus.OK);
    }

    private boolean isRateLimitExceeded() {
        // Implement logic to check if rate limit is exceeded
        // Example: Check request count within a time window
        return false;
    }
}

The secure implementation:

  • Implements rate limiting: Checks if the rate limit is exceeded before processing the request.

  • Returns appropriate HTTP status codes: Uses HttpStatus.TOO_MANY_REQUESTS to inform the client when the rate limit is exceeded.

Implementing Rate Limiting: Code Level vs. System Level

Code Level Rate Limiting

Implementing rate limiting at the code level can help mitigate Denial of Service (DoS) attacks, but it may not completely eliminate the threat. Here’s why:

Benefits:

  • Fine-grained Control: Allows developers to implement custom rate limiting logic based on specific application requirements.

  • Immediate Feedback: Provides immediate response and control over the request rate within the application logic.

  • Flexibility: Can be tailored to specific endpoints and user roles within the application

Limitations:

  • Performance Overhead: Adds additional processing burden on the application server, which could affect performance under high load conditions.

  • Scalability Issues: May not scale efficiently with very high volumes of traffic, as the application server itself needs to handle the rate limiting logic.

  • Limited Protection: While it can help reduce the impact of DoS attacks, it may not be sufficient to handle very large-scale attacks or sophisticated attack patterns.

System Level Rate Limiting

On the other hand, implementing rate limiting at the system level (e.g., using an API Gateway, load balancer, or a dedicated rate limiting service) offers several advantages:

  • Scalability: Can handle higher loads and distribute requests more efficiently across multiple servers.

  • Centralized Management: Provides a centralized mechanism to manage rate limiting policies across multiple services and applications.

  • Offload Processing: Offloads the rate limiting logic from the application server, allowing it to focus on core application logic.

  • Enhanced Protection: Offers better protection against large-scale DoS attacks by leveraging distributed architectures and advanced filtering mechanisms.

Which is Better?

Both approaches have their merits, and often a combination of both is used to achieve optimal security and performance:

  • Code Level Rate Limiting is better when you need:

    • Fine-grained control over specific request handling and business logic.

    • Custom rate limiting rules that are tightly coupled with application-specific requirements.

  • System Level Rate Limiting is better when you need:

    • High scalability and performance to handle large volumes of requests.

    • Centralized management of rate limiting policies across multiple services and applications.

    • Simplicity in maintaining the codebase by offloading rate limiting to external components.

Key Points for Developers

  • Implement Rate Limiting: Set limits on the number of requests a client can make within a specific timeframe.

  • Monitor Resource Usage: Keep track of resource consumption (CPU, memory, etc.) to prevent server overloads.

  • Use Proper Validation: Validate request payloads and query parameters to prevent excessive resource consumption.

  • Notify Clients: Inform clients when rate limits are exceeded and provide information on when they can make additional requests.

Summary and Key Takeaways

Lack of Resources & Rate Limiting can lead to significant performance issues and security vulnerabilities. By implementing rate limiting, monitoring resource usage, and validating requests, developers can ensure the availability and reliability of their APIs. Choosing between code level and system level rate limiting depends on the specific requirements, scalability needs, and complexity of the application.

In summary, while code-level rate limiting can help mitigate DoS attacks, implementing rate limiting at the system level is generally more effective for large-scale protection and scalability. A combination of both approaches can provide comprehensive security and resilience against DoS attacks.

Reference Links

PreviousExcessive Data ExposureNextBroken Function Level Authorization

Last updated 5 months ago

Was this helpful?

OWASP API Security Top 10:

Spring Security Documentation:

Spring Data JPA Documentation:

Docker Cheat Sheet:

OWASP API Security Top 10
Spring Security Documentation
Spring Data JPA Documentation
Docker Cheat Sheet