The Scourge of SQL Injection for APIs

In a report published in May 2024, cybersecurity firm Eclypsium outlined key vulnerabilities discovered in the F5 Big IP Next device. It’s another sobering reminder of the challenges faced in securing APIs when a highly regarded security company like F5 launches a new flagship product with all-too-familiar vulnerabilities like SQL injection and SSRF.

Among the vulnerabilities reported by Eclypsum, unauthenticated SQL injection deserves special attention. Injection attacks are very common and this was arguably the most dangerous vulnerability in this case, because it provided the easiest entry point for an unauthorized user.

Injection attacks are often successful when developers fail to define and enforce appropriate constraints on API input. This appears to be what happened in this case.

 

Follow the API data

The F5 API endpoint in question is documented here. This is a user login operation. Both the username and the provider_name fields were found to be vulnerable to injection attacks, although the provider_name field is the one specifically vulnerable to SQL injection.

Note the schema description for provider_name as “non-empty string”. It’s quite vague!

F5 BIG-IP Next Central Manager API Specifications

 

Jumping into F5’s OpenAPI file for the same API data, the requirements set for the provider_name input are simply that it must be a string with a minimum length of 1. 

F5 BIG-IP Next OpenAPI file

 

Again this is a very vague definition of the API’s input. It gives hackers enough leeway to try different attack patterns on the API and see what works. In the case of the BIG IP Next device, this is the malicious pattern for provider_name that worked:

"LDAPP'or' name = (select case when (password like concat({full_guess})) then chr(76)||chr(111)||chr(99)||chr(97)||chr(108) else chr(76) end from mbiq_system.users where username like concat({encoded_user}) limit 1)"

That doesn’t look like a valid provider name! Why was this input allowed? 

Because it’s a string and it’s more than one character long. Remember, this was the only requirement set for the provider_name input. The hacker’s malicious input met that requirement. The API requirement is the vulnerability!

To prevent injection vulnerabilities developers need to set precise requirements on API input fields. By documenting those requirements formally, using OpenAPI, it provides a common reference for developers to code to, and testers to verify against. 

Documenting requirements is not a security solution in itself. But this is a well-established practice for producing reliable software. Poorly defined API requirements infiltrate the development and testing phases as vulnerabilities, and ultimately into production where, as evidenced by this case, they can be discovered and exploited. 

 

Prevent vulnerabilities at the source

Let’s take the F5 case as an example and think about how to define, implement and test API requirements to avoid SQL injection vulnerabilities during API development.

 

Locate missing requirements 

We start in the OpenAPI file. The F5 OpenAPI file has over 81,000 lines. How can a team find the missing API requirements? 

42Crunch API Security Audit reveals missing or incomplete API requirements in OpenAPI files. In the case of F5, it immediately flags a vulnerability with the provider_name field, which lacks precise constraints on the data. 

API Security Audit finds a vulnerability in the F5 OpenAPI file

 

Complete the API requirements

So now we know what’s missing. How can we help developers add API requirements consistently and correctly across the team?

Data dictionaries are centralized repositories of formats and patterns for commonly used API data fields. Developers can refer to the data dictionary to ensure consistency in applying constraints on API data.

For this example let’s assume the requirement for the provider_name field is as follows:

provider_name must be 1-64 characters long, and use lowercase letters, numbers and underscore characters only.

This requirement could be stored in a data dictionary and shared with developers for reference or used for auto-completion of requirements:

Auto-complete API requirements for the provider_name

 

Note that this simple requirement would have been enough to remove the SQL injection vulnerability. In fact, just setting an upper limit of 64 characters on the input would have blocked the SQL injection on the F5 device, since the attack pattern was longer than 64 characters.

The more specific the requirement, the less room a hacker has to attack your API.

 

Test the API

Now that the provider_name requirement is complete and documented, has the API developer implemented the correct constraints in the API code? 

It is the responsibility of the API testing team to verify whether the API runtime behavior conforms to the expected behavior. Does the API accept malicious SQL injection patterns or does it securely reject input that doesn’t match the requirements:

provider_name must be 1-64 characters long, and use lowercase letters, numbers and underscore characters only.

This test is simple to run manually. But if we are talking about checking the requirements on the entire OpenAPI file (all 81,000+ lines) then 42Crunch API Conformance Scan is the right tool for the job. Conformance Scan takes the OpenAPI file as input and tests whether the API enforces each of the requirements (although developers can also test API operations one by one). 

In this example, using a simulation of the F5 API endpoint, Conformance Scan attempts to bypass the requirement by sending the API a provider_name that exceeds the 64 character maximum.

API Conformance Scan finds the vulnerability in the API

 

The expected response from the API is HTTP 400 bad request, since the input data is invalid.

However the actual response from the API is 404. Understanding the difference between 400 and 404 is important. The 404 response indicates that the API not only accepted the invalid provider name, but even tried to use it to search the database. This demonstrates that the API is vulnerable to injection attacks via malicious input.

So, using API Conformance Scan, the team could have identified the vulnerability in the API code and prevented the breach in production.

By leveraging OpenAPI as a requirements specification for your API, API teams can align your security goals with development and testing best practices. 

 

Tools for API Teams

API Security Audit and API Conformance Scan are both available as IDE plugins for VSCode, Intellij or Eclipse. 

You can try both API tools for free today using the Freemium option. See the 42Crunch website for details: https://42crunch.com/freemium/