C# API - Common Security Threats & Vulnerabilities - Part 1/2

1. Improper Assets Management

Improper Assets Management is a common type of security problem arising from inadequate access control restriction and/or the failure to properly implement security controls against undocumented or old versions of application API endpoints, source code repositories, or access to application development environments e.g. development, production, or staging environments.

To test this against the /api/v3/validate-code endpoint, Bob attempts to replace the version v3 to the following within the API URL:

To test whether v1 token validation endpoint /api/v1/validate-code is vulnerable to a brute-force attack, Bob creates a python script bruteforce.py that runs the curl command against token validation endpoint and submits a 4 digit token for verification.

 Mitigation

APIs tend to expose multiple endpoints over traditional web applications, making proper and updated documentation highly important.

To address this, proper hosts and deployed API version inventory also play an important role to mitigate issues such as deprecated API versions and exposed endpoint routes available in live systems. 

Further, to mitigate against vulnerabilities caused by improper asset management, developers should always make sure that no outdated or legacy API endpoints are available for use in the production environment.

2. Excessive Data Exposure

Excessive Data Exposure issues are a class of vulnerabilities that arise when an API returns excessive amounts of data to the client, which may be used by a potential attacker to gain access to sensitive information.

Having submitted Alice's leaked password reset token URL, Bob has managed to load the password reset page, thereby allowing him to successfully change Alice's account credentials and hijack her DesignDECK account!

3. Broken Object Level Authorization

Broken Object Level Authorization is a type of security vulnerability allowing attackers to exploit API endpoints by manipulating the ID of an object that is sent within the request. This may lead to unauthorized access to sensitive data. This issue is extremely common in API-based applications because the server component usually does not fully track the client’s state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access.


Bob attempts to modify the userId parameter by changing its value from 4673920 to 4673921.


Mitigation
Developers must ensure role-based access controls checks are implemented to ensure that the user has the required privileges to access the requested resource.

string userId = SessionManager.GetCurrentUserId(); if (!userId) { return Forbid("You are not authorized to perform this action."); }

4. Broken User Authentication

Broken User Authentication refers to a class of vulnerabilities, which allow attackers to assume other users' identities due to a poorly implemented API authentication.

By simply brute-forcing every possible token value, Bob has successfully managed to bypass Coinpay's Two-Step Verification and further managed to access her Coinpay account with Alice's stolen credentials.

Mitigation 

There are many methods to stop or prevent brute-force attacks depending on the feature and business use case within the application. For example, in Coinpay's scenario, a long term fix to prevent token-based brute force attacks would be to:

Increase the token length from 4 characters to a minimum of 8, thereby increasing the time it takes to attempt every possible token combination.

Add progressive delays or rate-limit the attempts to submit a new token.

Add CAPTCHA to log in, registration, and two-factor authentication forms.

// appsettings.json "IpRateLimiting": { "EnableEndpointRateLimiting": true, "GeneralRules": [ { "Endpoint": "/api/validate-code", "Period": "1h", "Limit": 3 }, ] }

5. Lack of Resources & Rate Limiting

Lack of Resources & Rate Limiting refers to a vulnerability whereby the published APIs lack insufficient resources or limits on the rate of access per user or per client application, resulting in poor performance of the application and further making it susceptible to Denial of Service (DoS) or brute-force attacks or user enumeration attacks depending on the API's implementation.

Bob creates a python script called bruteforce.py  that runs the curl command against /api/sign-up endpoint to identify phone numbers that are registered on the platform. 

Mitigation

To effectively mitigate against this kind of attack, developers should implement a limit on how often a client can call the API within a defined timeframe.

Additionally, a generic response message should be displayed as a response instead of an field-specific one, regardless of whether or not the username, email or account is valid.

Let's see how the above best practice can be applied to our vulnerable code example to prevent User Enumeration attacks.

// appsettings.json

"IpRateLimiting": {

  "EnableEndpointRateLimiting": true,

  "GeneralRules": [

    {

      "Endpoint": "/api/sign-up",

      "Period": "1h",

      "Limit": 2

    },

  ]

}

6. Broken Function Level Authorization

Broken Function Level Authorization relates to the security issues arising due to improper validation of the authorization level of the user of an API and the function that it is intended to perform. This security issue is common with modern applications implementing improper checks due to the prevalence of several types of roles, scopes, and/or groups leading to a complex user access hierarchy.

 Usually, the attacker figures out the “hidden” admin API methods and invokes them directly.

Mitigation

To effectively mitigate against Broken function-level authorization vulnerabilities, developers must enforce proper authentication and authorization checks for each API endpoint, even if some of them are "hidden" from the user interface perspective.