API Security Testing

  1. API1:2019 Broken Object Level Authorization

    APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.

  1. API2:2019 Broken User Authentication (This one requires manual checking)

    Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising a system’s ability to identify the client/user, compromises API security overall.

  1. API3:2019 Excessive Data Exposure

    Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.

  1. API4:2019 Lack of Resources & Rate Limiting (not considered)

    Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.

  1. API5:2019 Broken Function Level Authorization

    Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

  1. API6:2019 Mass Assignment

    Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually leads to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.

  1. API7:2019 Security Misconfiguration (requires manual checking)

    Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

  1. API8:2019 Injection

    Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

  1. API9:2019 Improper Assets Management

    APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

  1. API10:2019 Insufficient Logging & Monitoring

    Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Proposed Method

Overview

1 and 5: active checker

6 and 8: response validation

Oracle: (1) response code (2) content structure - json (xml) similarity

Workflow

  1. Normal discovery: api graph via dynamic fuzzing

  2. Two types of extension testing strategy, can be combined:

    1. Sequence validation: give example (use after free)

    2. Payload fuzzing: give example (payload)

    3. Combined: malicious object creation

  3. Benchmark creation: OWASP and testing result

Type of Violations (normal baseline)

Position Baseline Payload Result Type
Before Injection Point 200+ 500+ Normal error handle 0
At Injection Point 200+ 500+ Normal error handle 1
After Injection Point 200+ 500+ Injection triggered error 0 or 2
Any point 500+ any+ Normal error handle 0
Any point 400+ 200+ Auth bypass/access violation 3
  • type 0: original type of violation
  • type 1: a normal 500 error caused by improper server handle of injected item
  • type 2: malicious object creation
  • type 3: auth bypass

Existing problem

Random id generation. This may not be a problem in fuzzing; but in security testing it’s a bit annoying, bringning in many false positives.

To-dos

  • Payload checking oracle implementation:
  • Payload fuzzing implementation (currently random only)
    • Payload byte-level injection
    • Payload
  • Juice-shop api examples