API Security in the Wild
A few months ago, I presented at a University of New Brunswick undergraduate class and taught students how to secure their Web APIs. At the end of the class a student asked, “which category of bugs is more prevalent and more dangerous?”. At first it sounds like an easy question. After all, remote code execution related bugs such as SQL injection and command injections are very dangerous. I could not come up with a correct answer for the first part of the question. This simple question was my motivation to analyze publicly disclosed vulnerability reports in the HackerOne website (a famous vulnerability coordination and bug bounty platform). The following is the result of my study.
Results and Analysis
I utilized the following Google query to find the reports:
site:hackerone.com inurl:/reports/ “API”
The Google search found 590 items and after removing duplicate and unrelated reports, there were 223 relevant reports. The following chart shows most reported bugs were related to the JSON based APIs. I believe it does not mean that JSON based APIs are more vulnerable, but it shows XML based APIs such as SOAP and XML-RPC are deprecated these days.
I categorized all the 223 reports into 26 classes which can be seen in the following figure and table. As expected, "Information Disclosure” ranked as the highest with 16 percent of reports. Out of 35 reports, 6 of them were related to the WordPress misconfiguration. I had expected more than that as 35 percent of all Websites on the Internet are powered by WordPress!
It is worth noting that more than 60 percent of the bugs in GraphQL based APIs are Information Disclosure, which is predictable as GraphQL is a relatively new query language and developers might not have applied the best security practices. Furthermore, some developers did not turn off the debug mode when deploying the website which lead to disclosing information on crashes. In some cases, there are old or secret endpoints that hackers were able to abuse and extract extra information. In other cases, by tampering with parameters and using secret parameters, hackers were able to disclose private information. Some hackers used cross-site information leakage techniques to embed unwanted code into their website to obtain private information of the user by checking different status codes that the victim’s site provides.
The next prominent category is “Improper Access Control” with 12 percent dominance. The majority of these bugs are related to the lack of applying sufficient checks. For example, in some cases the developer forgot to expire sessions or the attacker duplicated a session. A few of these bugs were also related to cross-origin resource sharing (CORS) policy misconfigurations. For example, an attacker could inject “Origin: http://evil.com” into the header.
“Cross-site scripting” which is an old school category of bugs ranked in the second place. One of the reasons could be that developers did not expect to get an HTML tag as an API input! By the way, a simple sanitization or filtering developers could avoid this category of bugs.
Around 11 percent of the reports fall under the “Improper Authentication/Authorization“ category, ranging from simple mistakes such as lack of authorization for an important endpoint to complex situations such as race condition in OAuth 2 API implementations.
|
Name |
Count |
|
Information Disclosure |
36 |
|
Improper Access Control |
26 |
|
Cross-site Scripting (XSS) |
26 |
|
Improper Authentication/Authorization |
25 |
|
Cross-Site Request Forgery (CSRF) |
17 |
|
Insecure Direct Object Reference |
14 |
|
Server-Side Request Forgery (SSRF) |
12 |
|
Business Logic Errors |
11 |
|
Denial of Service |
10 |
|
Rate limit |
9 |
|
Open Redirect |
6 |
|
XXE |
6 |
|
Command Injection |
4 |
|
Race condition |
3 |
|
SQL Injection |
2 |
|
Insufficient Session Expiration |
2 |
|
Cross-origin resource sharing |
2 |
|
Deserialization of Untrusted Data |
2 |
|
Path Traversal |
2 |
|
Remote File Inclusion |
2 |
|
Client-Side Enforcement of Server-Side Security |
1 |
|
Improper Input Validation |
1 |
|
Modification of Assumed-Immutable Data (MAID) |
1 |
|
Exposed Dangerous Method or Function |
1 |
|
CRLF Injection |
1 |
|
Null byte attacks |
1 |
Cross-Site Request Forgery is noted as a dangerous category of attack and surprisingly 8 percent of reports were associated with this type of attack. By using this type of attack, one can make API calls on behalf of other users. Interestingly, many of the APIs had some levels of CSRF protection but attackers were able to bypass them (by spoofing "X-Requested-With"). To explain CSRF protection bypassing methods, we would need to write another article.
Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly (database records or files). In extreme cases, the attacker gains access to financial information of other users (credit cards, SIN, …) or the attacker can modify users’ accounts. Around 6 percent of the reports fall are under this category. Aside from putting proper checks to avoid IDOR, the other thing to consider is to avoid using sequential IDs to access the data. For example, having this structure http://example.com/api/getvideo/1 is not a good idea as the attacker can iterate through the video ID. If the proper checks are not in place, the attacker can dump all data.
Most Server-Side Request Forgery (SSRF) reports are associated with file upload, proxy or webhook services. As most documentation about SSRF vulnerabilities point out, these features are the first places one would go to look for SSRF vulnerabilities in your API. Also, any file that can contain a URL and would be parsed by the API can potentially cause the vulnerability such as SVGs, JPGs, XMLs and JSONs.
What was surprising in the other API bugs categories was the low number of injection attacks (SQL and command injection). This category is ranked as first in the top 10 OWASP vulnerabilities in 2020 (less than 3 percent of reports are associated with this category).
GraphQL is an alternative (not a replacement) to REST API and it is very useful in the scenarios that one handles for complex data schemas. In the following, you can see the number of bugs reported related to GraphQL APIs. It is interesting that I could not find some of the well-known security issues such as maximum query depth or throttling based on query complexity that are listed in security related GraphQL best practices.
Conclusion
Currently most modern websites and mobile applications use APIs to be functional. In this report we analyzed 223 Web API bug reports on the HackerOne platform, and we explained the most prominent bug categories. We have provided some clues for developers and pentesters to find vulnerable endpoints. By using the findings of this report, the reader will gain a deeper understanding of API vulnerabilities.
