Be honest. Have you learned more from your successes or your failures? Exactly: "from the ashes of disaster grow the roses of success," as the immortal song from the musical Chitty Chitty Bang Bang goes. Things that don't work well are usually the best starting point for doing better; and in science, technology engineering and medicine (STEM), broken things often bring solutions sharply into focus.
The OWASP Project thinks so too, and so created an API that was deliberately vulnerable to teach us all a thing or two about API security risks. Here's what we learned from crAPI about API security, and how a Web Application Firewall (WAF) can help you take things one step further.
How security vulnerabilities put applications at risk
There is a proliferation of public Web APIs available to developers writing Web applications for every possible use case and purpose, in addition to an uncountable myriad of in-house APIs developed for specific applications. These Application Programming Interfaces (APIs) pull and push information to or from a back-end application, bringing with them a number of technical benefits versus directly talking to the application or data source. Web APIs can provide the following:
- HTTP access to data endpoints, usually via XML or JSON string responses.
- An interface for use by other applications, both internal and external, decoupled from how the application works. This makes a Web API ideal for connecting to Web front-ends, mobile apps and task automation tools.
- A specification for data transactions that isn't tied to a specific implementation, potentially allowing the underlying application and data platform to change (or even be completely replaced with another) without breaking external dependencies.
- Access control, management and validation of external requests, including authentication and Single Sign-On (SSO), such as via OAuth and ADFS.
- Endpoint hosting via either a Web server (e.g. Apache, Nginx or IIS) or a dedicated API service without directly exposing the application's platform.
On the "flip side," however, every Web API has the potential to introduce a new set of vulnerabilities that need to be addressed if the APIs, users, and data are to remain secure. If not, they are likely to be subject to any number of security threats which developers will need to mitigate. Many of these fall within OWASP's Top 10:
- Broken access control
- Cryptographic failures
- Injection
- Insecure design
- Security misconfiguration
- Vulnerable and outdated components
- Identification and authentication errors
- Software and data integrity failures
- Security logging and monitoring failures
- Server-side request forgery (SSRF)
Vulnerabilities in the OWASP Top 10 categories have the potential to take down applications, break critical services, expose your data, and make or break reputations, so the stakes are extremely high — particularly as each application type has a unique attack surface which requires specific steps in order to secure it.
But where do you begin when it comes to securing your apps? By breaking stuff, obviously!
crAPI is vulnerable by design
Never let it be said that the OWASP Project doesn't have a sense of humour: the Completely Ridiculous API (crAPI) is an open-source, intentionally-broken API crafted to provide a "working model" of the OWASP Top 10 vulnerabilities. The intent of crAPI is mainly to teach coders and systems administrators how to avoid falling victim to common security pitfalls. It also has a secondary use for evaluating the effectiveness of a WAF solution in mitigating core threats in insecure applications, and can be helpful in a lab environment for developing custom WAF rules and testing them.
The OWASP crAPI has an imaginary objective of offering car maintenance services. The beauty of this sandbox API is that it mirrors all the functionality you would find on a normal website — an ingress service, mail service, vehicle workshop endpoints, user and authentication endpoints, community blog and commentary endpoints, and a SQL database. Users are also able to create accounts, comment on blogs, search for mechanics, buy car accessories, and book a service. However, as the name suggests, the implementation of crAPI is definitely not as secure as it might be, to put it mildly.
To get started with an instance of crAPI on your local system, check out this quick-start guide — please note, however, that you will need to install Docker and docker-compose on your system before you begin. By completing a series of challenges, developers are able to work their way through the long list of security vulnerabilities within the application and learn what not to do, and what to do, when developing their own Web APIs.
What did we learn from OWASP's crAPI?
Well, we learned how not to build a Web API by...
- ...managing to leak sensitive information of another user’s vehicle, and accessing reports submitted by other users (BOLA vulnerabilities)
- ...resetting the password of a different user (broken user authentication)
- ...finding an API endpoint that leaks sensitive information and internal video properties (excessive data exposure)
- ...performing a Layer 7 DoS using a ‘contact' feature (rate limiting)
- ...deleting the video of another user (BFLA)
- ...getting an item for free, getting a refund for an item that was never purchased, updating internal video properties (mass assignment)
- ...making crAPI send an HTTP call to www.google.com and return an HTTP response (SSRF)
- ...getting free coupons without a coupon code (noSQL injection)
- ...redeeming a coupon that had already been claimed (SQL injection)
- ...finding an endpoint that didn't perform user authentication checks (unauthenticated access)
- ...finding a way to forge a valid JWT token and get full access to the platform (JWT vulnerabilities).
By walking a mile in the shoes of a "malicious actor," we thankfully learned how to close some of those loopholes. Without fear of losing our jobs, I might add — phew!
Being crAPI will only get you so far...
It is worth noting that although crAPI does an excellent job of providing a demonstration of common technical vulnerabilities, the most serious API security issues "in the wild" tend to be far more basic and fundamental in nature. These are caused by system administration errors rather than a faulty API implementation, and often involve configurations where the API itself can be entirely bypassed. In such a scenario, even if the API itself has been developed with good design practices in mind to mitigate the security vulnerabilities outlined in the OWASP Top 10, these efforts will sadly be in vain.
Unfortunately, such vulnerabilities are borne out by our own experience in supporting our customers. For example, we have seen APIs hosted on Web servers that were accidentally configured with permissions that allowed external clients to directly access both the API internals and the back-end application, allowing data access without any API authentication at all. In some cases, customers have effectively DoS attacked themselves by unintentionally sending a huge number of requests to their API from a mobile application due to a software bug.
Of course, when it comes to practically mitigating the OWASP Top 10, there is no substitute for a WAF combined with a secure, robust API implementation hosted in a well-maintained server environment. In summary, the security basics in your environment must be adequate for any other measures to be effective.
How can a WAF mitigate the OWASP Top 10?
The OWASP ModSec Core Rule Set in our WAF is designed specifically to address the Top 10, offering a genuine security benefit against injection and DoS attacks in particular. Of course, all WAFs have their limitations. For example, a WAF cannot make an insecure application secure, and it cannot secure an API hosted in an insecure environment — for example, one where the back-end is mistakenly exposed, as I mentioned above.
However, there are benefits to using and possibly extending the ModSec Core Rule Set (CRS) in our WAF as a mitigation measure. This can be very useful if it is difficult or impossible to fix the faulty API itself, or if the vulnerability is caused by the host environment rather than the API application in a way that cannot be patched.
Open source is the secret sauce
crAPI is yet another example of the power and value of the open source community from which OWASP was founded. By encouraging open, transparent conversations about Web application security issues, developers, security enthusiasts, and API tools can all learn lessons, contributing to the ongoing quest for better application security.
It doesn't end there, however. The crAPI is just one introductory learning tool released by OWASP. The OWASP ModSec Core Rule Set (CRS) that we use in our WAF provides tangible ways of preventing some of the vulnerabilities identified by the OWASP Top 10.
For more practical hints and tips from OWASP on how to keep your apps secure, the Web Application Security Testing Checklist is an excellent starting point for understanding what to check for. For more on our WAF and how to use it, check out our comprehensive WAF blog series or contact our technical team for honest and straightforward advice.