Web Application Security – API Data Exposure

• April 29, 2021
• David Anderson

API’s are wonderful…until they leak protected information

Authored By: Sedric Louissaint

In this age of technology, APIs arguably have become the core essential piece of web-based services and applications. APIs are used to make “calls” or “requests” to send or receive information between two systems. Some APIs are utilized to transmit sensitive data, such as credit card numbers or medical information. It is important that organizations evaluate their applications to gain confidence that the APIs are secured and hardened. As an example, APIs should require proper authentication and authorization in order to use.  APIs that interact with sensitive information or perform sensitive actions should require authorization for every request, such as the use of a bearer token. The lack of authorization on sensitive APIs directly corresponds to the OWASP API Security Top 10 issues, specifically “Broken Object Level Authorization.”

Example 1 – HIPAA Data

CLA performed a web application penetration test for an organization in the government sector that handles sensitive medical and personal information. This web application was accessible from the internet for anyone is the world to interact with. During the engagement, we identified multiple instances of authentication not being required to interact with the API. In layman’s terms anyone on the internet with the correct prerequisite knowledge could abuse the API to extract the HIPAA protected data.

Additionally, the API also provided the functionality to upload and delete medical documents. We identified we could have abused the API to delete all of the medical data associated with each account.

Throughout the engagement, CLA collaborated with the client and provided the necessary details for the client to remediate the vulnerability. Had a malicious threat actor discovered and abused this vulnerability to gain access to protected health information, it could’ve potentially led to over a million dollars in HIPAA violation fines.

Example 2 – PCI Data

During an internal penetration test for a financial institution, CLA identified a web application that was utilized for managing debit and credit cards issued by the institution. The application supported functionality to perform administrative related tasks, such as looking up debit/credit card information, order/issue a new card, block a card, and raise point of sale (POS) limits. Through this functionality, the full details for any customer’s account and debit/credit card information could be extracted by anyone with access to the application. Specifically, because no authorization checks were performed by the API.

CLA used the graphical interface of the application to gain an understanding of the underlying API structure and was able to determine the specific API requests used to retrieve card data.

It was possible to abuse the APIs within this web application to extract all card data managed by the application. During the preliminary observations meeting we held once fieldwork was complete, we communicated these findings to the organization. The organization informed us this was actually an application in development and was not in production yet; however, the data in use was live, production data.

This was yet another case of organizations APIs being left wide open for anyone to use.  In addition, PCI does not allow production data to be utilized in test environments. Specifically, control 6.4.3 states that “production data (live PANs) are not used for testing or development.” This exposed compliance issues beyond the fact that sensitive data was not properly protected.

Conclusion

Not securing your APIs with authentication and authorization is equivalent to leaving your front door wide open. Sometimes, organizations think they are doing everything right to secure the data they are responsible for but, unbeknownst to them, an employee or vendor may have made a mistake that exposes sensitive information. Had a malicious threat actor abused these APIs to gain access to sensitive information, it could’ve cost them in the form of fines or, more importantly, their customers’ trust.

If you are interested in discussing application testing or securing your IT systems, please reach out to me.

Tags: api, penetration test, pentesting, security, web app, webapp, Information Security, Network Security, Penetration Testing | Comments Off on Web Application Security – API Data Exposure