An overview of the most common security misconfigurations, a constant threat against API implementations.
You’ve probably heard of the OWASP top ten or the top ten vulnerabilities that threaten web applications. OWASP also periodically selects a list of top ten vulnerabilities that threaten APIs, called the OWASP API top ten. The current API top ten are Broken Object Level Authorization, Broken User Authentication, Excessive Data Exposure, Lack of Resources & Rate Limiting, Broken Function Level Authorization, Mass Assignment, Security Misconfiguration, Injection, Improper Assets Management, and Insufficient Logging & Monitoring.
Security misconfigurations are a constant threat against both APIs and non-API applications alike. Today, let’s talk about security misconfigurations in APIs, and how they can affect APIs.
Verbose error messages
First of all, one of the most common security misconfigurations is sending verbose error messages to the user. These verbose error messages might contain stack traces, information about the system, such as the server version or underlying database structure, and give the user insights into how the application works under the hood. In this case, a malicious user can force an error message from the application (through providing malformed or illegal inputs) to gather information about the server.
A lot of default 404 pages also contain custom signatures that allow attackers to fingerprint the technology used, an example being the Ruby on Rails framework.
Misconfigured HTTP headers
Another common configuration is misusing or missing HTTP headers. There are many HTTP security headers that help enhance the security of an application. If they are not properly configured, attackers can often find security holes that allow them to exfiltrate data, or perform common web attacks on the application’s users.
For example, the Content-Security-Policy (CSP) header controls which resource the browser is allowed to load for a page. It should be set to disallow scripts from random domains, inline scripts, and event-handling HTML attributes to prevent XSS (cross-site scripting) attacks. For details on how to configure CSP securely, read my post on the topic here:
Intro to the Content Security Policy (CSP)
CORS (Cross-Origin resource sharing) misconfiguration is also an issue stemming from the misconfiguration of HTTP headers. Cross-origin resource sharing (CORS) is a safe way to relax the same-origin policy (SOP). It allows servers to explicitly specify the list of origins that are allowed to access its resources via the Access-Control-Allow-Origin header. Access-Control-Allow-Origin should be configured to only allow cross-origin communication from trusted sites. Misconfigured CORS policy allows attackers to steal confidential data by messing with cross-origin communication. You can read more about how attackers can exploit misconfigured CORS here:
Hacking the Same-Origin Policy
Unnecessary services or HTTP methods
Another common misconfiguration is failing to close down unnecessary services or HTTP methods. For example, let’s take a look at the example I mentioned in my previous post. The access control bug I mentioned is caused by not closing down unused HTTP methods.
API Security 101: Broken Function Level Authorization
The API allows its users to retrieve blog posts by sending a GET request to an endpoint like this:
GET /api/v1.1/user/12358/posts?id=32
This request will cause the API to return post 32 from user 12358. Since all posts on this platform are public, any user can submit this request to access others’ posts. However, since only the users themselves should modify blog posts, only user 12358 can submit POST requests to modify or edit the post. If the API does not place the same restrictions on requests sent with less popular HTTP methods, like PUT and DELETE, malicious users might be able to modify or delete other users’ posts by using a different HTTP method.
DELETE /api/v1.1/user/12358/posts?id=32
We also talked about how the site allows admins to view the site’s statistics via a special API endpoint:
GET /api/v1.1/site/stats/hd216zla
This admin endpoint does not implement any user-based restrictions. The site relies on the fact that the URL endpoints contain a random string at the end to prevent unauthorized users from accessing it. This practice is called “Security through Obscurity,” which means to increase security by withholding knowledge from outsiders.
But security through obscurity is not reliable as the only security mechanism. If an attacker can find out the obscure URL via an information leak, the attacker can access the sensitive functionality hidden behind the endpoint. Leaving sensitive services like this one open to outsiders can cause malicious users to gain access to it.
Insecure default configurations
Many third-party dependencies like databases and web frameworks are insecure by default and require developers to tighten up security via custom configuration. For instance, older versions of MongoDB were accessible to the internet and required no authentication by default. This caused thousands of databases to be exposed to the public if the developer did not change default configurations.
Insecure default configurations like this example can cause a lot of security issues if the developer is not aware of its consequences. As of right now, MongoDB still does not require authentication by default. To see how you can set up authentication to your MongoDB database, read the docs here: https://docs.mongodb.com/manual/tutorial/enable-authentication/.
Note that this list is not a list of all the possible security misconfigurations that can happen to an API, but an overview of the most common ones. I hope that this list will help you stamp out the most common security misconfigurations in your API systems and help you consider other places that might be insecure in your API. What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.
Want to learn more about application security? Take our free OWASP top ten courses here: https://www.shiftleft.io/learn/.
Top comments (0)