Recon the target, find the whole attack surface by passive or active recon.

hidden and public parameters finding is the goal and other things

browse the application as it was intended and proxy the traffic to burp/zap/swagger/postman

Once you have an idea of how the web app functions, dig deeper by deploying passive and active reconnaissance techniques.

Passive : [obtaining information about a target without directly interacting with the target’s systems]

• OSINT
• Google Dorking
• GitDorking
• TruffleHog
• Shodan
• Wayback Machine

Active :

• Nmap
• OWASP Amass
• Directory Brute-force with Gobuster
• Kiterunner
• DevTools

Endpoint Analysis : Reverse Engineering the APIs, making requests and analyzing responses and look for Excessive Data Exposure.

• API is not documented then, build own collection of requests by Postman or mitmproxy2swagger.
• using different params, headers, path variables, and information included in the body of the request look for :
  • A response that includes more information than what was requested
  • Sensitive Information that can be leveraged in more complex attacks

Excessive Data Exposure :

Vulnerable if -

The API returns sensitive data to the client by design. This data is usually filtered on the client side before being presented to the user. An attacker can easily sniff the traffic and see the sensitive data.

Example Attack Scenarios

Scenario #1

• The mobile team uses the /api/articles/{articleId}/comments/{commentId}endpoint in the articles view to render comments metadata. Sniffing the mobile application traffic, an attacker finds out that other sensitive data related to comment’s author is also returned. The endpoint implementation uses a generic toJSON() method on the User model, which contains PII, to serialize the object.

Scenario #2

• An IOT-based surveillance system allows administrators to create users with different permissions. An admin created a user account for a new security guard that should only have access to specific buildings on the site. Once the security guard uses his mobile app, an API call is triggered to:/api/sites/111/camerasin order to receive data about the available cameras and show them on the dashboard. The response contains a list with details about cameras in the following format {"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}. While the client GUI shows only cameras which the security guard should have access to, the actual API response contains a full list of all the cameras in the site.

Security Misconfiguration : Security misconfiguration includes missing system patches, unnecessary features enabled, lack of secure transit encryption, weak security headers, verbose error messages, and Cross-Origin Resource Sharing (CORS) policy misconfigurations.

• Using OWASP Zap manual explore feature and enabling HUD. use the web app as intended and the traffic should be getting proxied in zap. using attack mode we can scan for more.

API Vulnerable if -

• Appropriate security hardening is missing across any part of the application stack, or if it has improperly configured permissions on cloud services.
• The latest security patches are missing, or the systems are out of date.
• Unnecessary features are enabled (e.g., HTTP verbs).
• Transport Layer Security (TLS) is missing.
• Security directives are not sent to clients (e.g., Security Headers).
• A Cross-Origin Resource Sharing (CORS) policy is missing or improperly set.
• Error messages include stack traces, or other sensitive information is exposed.

Example Attack Scenarios

Scenario #1

An attacker finds the .bash_historyfile under the root directory of the server, which contains commands used by the DevOps team to access the API:

$ curl -X GET '[<https://api.server/endpoint/>](<https://api.server/endpoint/>)' -H 'authorization: Basic Zm9vOmJhcg=='

An attacker could also find new endpoints on the API that are used only by the DevOps team and are not documented.

Scenario #2

To target a specific service, an attacker uses a popular search engine to search for computers directly accessible from the Internet. The attacker found a host running a popular database management system, listening on the default port. The host was using the default configuration, which has authentication disabled by default, and the attacker gained access to millions of records with PII, personal preferences, and authentication data.

Scenario #3

Inspecting traffic of a mobile application an attacker finds out that not all HTTP traffic is performed on a secure protocol (e.g., TLS). The attacker finds this to be true, specifically for the download of profile images. As user interaction is binary, despite the fact that API traffic is performed on a secure protocol, the attacker finds a pattern on API responses size, which he uses to track user preferences over the rendered content (e.g., profile images).

Lack of Resources & Rate Limiting :

API Vulnerable if -

API requests consume resources such as network, CPU, memory, and storage. The amount of resources required to satisfy a request greatly depends on the user input and endpoint business logic. Also, consider the fact that requests from multiple API clients compete for resources. An API is vulnerable if at least one of the following limits is missing or set inappropriately (e.g., too low/high):

• Execution timeouts
• Max allocable memory
• Number of file descriptors
• Number of processes
• Request payload size (e.g., uploads)
• Number of requests per client/resource
• Number of records per page to return in a single request response

Example Attack Scenarios

Scenario #1

• An attacker uploads a large image by issuing a POST request to /api/v1/images. When the upload is complete, the API creates multiple thumbnails with different sizes. Due to the size of the uploaded image, available memory is exhausted during the creation of thumbnails and the API becomes unresponsive.

Scenario #2

• We have an application that contains the users' list on a UI with a limit of200 users per page. The users' list is retrieved from the server using the following query: /api/users?page=1&size=200. An attacker changes the sizeparameter to 200 000, causing performance issues on the database. Meanwhile, the API becomes unresponsive and is unable to handle further requests from this or any other clients (aka DoS).

The same scenario might be used to provoke Integer Overflow or Buffer Overflow errors.

Authentication Attacks : Since REST APIs are stateless they do not maintain state and require you to authenticate every time when you make a request. A username and password would have to be issued every time, then upon providing the correct credentials, a token would be issued to be used in subsequent requests.

• Classic authentication attacks like brute forcing and password spraying is to be used on the username-password in this type of attack.
• Token Attacks and Analysis
  • Using Burp Suite Sequencer, can help you identify predictable tokens and aid in token forgery attacks. But it requires thousands of tokens to analyze.
  • JWT Tokens : JWTs consist of three parts, all of which are base64 encoded and separated by periods: the header, payload, and signature. JWT.io can be used as a debugger.
    • You can spot a JWT token by looking if it consists of three periods and begin with "ey” (when you base64 encode a curly bracket).
    • compromise the signature secret then we should be able to sign our own JWT and potentially gain access to any valid user's account
    • command line tool JWT_Tool can also be used
    • If the algorithm is set to “none”. you should be able to clearly see the header, payload, and signature. From here, you can alter the information contained in the payload to be whatever you’d like. edit the payload, encode it and use it.

Is the API Vulnerable?

• Authentication endpoints and flows are assets that need to be protected. “Forgot password / reset password” should be treated the same way as authentication mechanisms.
• An API is vulnerable if it:
  • Permits credential stuffing whereby the attacker has a list of valid usernames and passwords.
  • Permits attackers to perform a brute force attack on the same user account, without presenting captcha/account lockout mechanism.
  • Permits weak passwords.
  • Sends sensitive authentication details, such as auth tokens and passwords in the URL.
  • Doesn’t validate the authenticity of tokens.
  • Accepts unsigned/weakly signed JWT tokens ("alg":"none")/doesn’t validate their expiration date.
  • Uses plain text, non-encrypted, or weakly hashed passwords.
  • Uses weak encryption keys.

Example Attack Scenarios

Authorization Attacks : test for authorization vulnerabilities including BOLA - Broken Object Level Authorization and BFLA - Broken Function Level Authorization. authentication process is meant to validate that users are who they claim to be.

• User A should only be able to access User A's resources and User A should not be able to access User B's resources.
• BOLA vulnerabilities occur when an API provider does not restrict access to access to resources.
• BFLA vulnerabilities are present when an API provider does not restrict the actions that can be used to manipulate the resources of other users.
• BOLA :
• BFLA :

Improper Assets Management : discovering unsupported and non-production versions of an API. earlier versions of the API may no longer be patched or updated. Non-production versions of an API include any version of the API that was not meant for end-user consumption

Finding :

Testing :

Mass Assignment : attacker is able to overwrite object properties that they should not be able to. API must have requests that accept user input, these requests must be able to alter values not available to the user, and the API must be missing security controls that would otherwise prevent the user input from altering data objects.

eg: attacker is able to add parameters to the user registration process that escalate their account from a basic user to an administrator’

Finding : (all about binding user input to data objects so find requests that : • Accept user input • Have the potential to modify objects)

SSRF : application retrieves remote resources without validating user input. attacker can supply their own input, in the form of a URL, to control the remote resources that are retrieved by the targeted server. When you have control over what resources a server requests then you can gain access to sensitive data or worse completely compromise a vulnerable host.