Project Description

Security Misconfiguration

Security Misconfiguration is currently ranked at number seven in the OWASP API top 10. There are several factors that might indicate a Security Misconfiguration. In some cases, the service’s default configuration could also qualify for a security misconfiguration vulnerability in the API. Security misconfigurations have always been a constant threat against API applications. Today, we will discuss security misconfigurations and how they can affect APIs.

What is A Security Misconfiguration?

There are many reasons why an API endpoint would be vulnerable to a security misconfiguration exploit. Sometimes it’s due to lack of appropriate security hardening across any part of the application stack, or most commonly, due to permissions on the cloud services being improperly configured. 

There are a few other causes for security misconfigurations in APIs. These include: 

  • Application sending verbose error messages to the user: Verbose error messages usually contain information about the system, such as the server version and the used database structure. This can potentially give threat actors insight into how the application works and communicates with the backend, which helps them with passive reconnaissance and the forming of an attack strategy.
  • Enabling unnecessary features such as HTTP verbs: This security misconfiguration can lead to excessive data exposure or privilege escalation issues. 
  • Missing Cross-origin resource sharing policy or a misconfigured CORS policy: A misconfigured CORS policy can allow a threat actor to steal confidential data by making malicious changes in the Access-Control-Allow-Origin header. 
  • Missing latest security patches and out of date system plugins: These can act as a gateway for newer threats. 

An example of a security misconfiguration vulnerability 

Let’s use a social media web application as an example. It has a sign-up feature, and upon signing up you can connect to other people and create a network. Just like social media apps, people in your network can view your profile, photos etc, and vice versa. 

When clicking to look at one of your connections’ photos, the following request is sent to the server:

GET /api/v1/yournetwork/user/101/photo?id=241

The request above will cause the API to return the photo with id 241 of the user with id 101. Since users are allowed to view each other’s photos, you will get a 200 Ok response to the sent request and you will be able to access the picture. 

Now, imagine if the API does not place restrictions on other HTTP methods like DELETE. In that case a threat actor would be able to send the same request with the DELETE method and delete your photo without having the permissions to do so. 

Such re quest would look like this: 

DELETE /api/v1/yournetwork/user/101/photo?id=241

Upon sending, if the threat actor gets a success response, then this API endpoint is misconfigured and is vulnerable to security misconfiguration. This vulnerability can often lead to much more severe issues than this example.

How to prevent the Security Misconfiguration vulnerability in your APIs

  1. Have an automated process to continuously evaluate how effective the configuration is in all environments.

  2. Don’t allow any unrequired HTTP methods for your APIs, and implement whitelist-based filtering of HTTP. As shown in the example above, if there is no restriction on other HTTP methods, threat actors may be able to exploit and escalate privileges horizontally or vertically.

  3. Don’t rely on this-party default configuration. The default configuration of many third-party dependencies is not secure enough. As a developer, you should write custom configurations to tighten up security for third-party dependencies.

  4. Conduct reviews whenever a critical or high severity vulnerability is patched. These reviews should include API components as well as the cloud services. If you are using an S3 bucket, the review should include the evaluation of bucket permissions.

  5. Implement a proper cross-origin resource sharing (CORS) policy. CORS is a commonly found vulnerability in many web applications. A proper CORS policy can stop threat actors from being able to make malicious edits in the Access-Control-Allow-Origin header, and consequently steal data. 

How to test for Security Misconfigurations

Many security misconfiguration vulnerabilities are missed out by penetration testers during manual testing. With that, we recommend including some automation while running manual testing. Many vulnerability scanners help find security misconfiguration vulnerabilities that we might miss out during manual testing. 

Fixing security misconfiguration vulnerabilities is crucial since some of these issues can lead to further vulnerabilities of high or critical severity. As mentioned above, if we follow a plan test routine along with implementation of solid policies, our resources should be secure.