BLOG

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/Ā 

Latest Resources

WEBINAR

Mitigate OWASP API risks through security-by-design

Learn best practices and mitigation steps for some of the OWASP API vulnerabilities through this 42Crunch API security best practice webinar
Nov 5, 2024
PST 9am | EST 12pm | GMT 5pm

NEWS

VicOne Partners with 42Crunch to Deliver Uniquely Comprehensive Security Across SDV and Connected-Vehicle Ecosystem

By Newsdesk | May 29, 2024

Collaboration pairs leaders in API and automotive cybersecurity to enable broad protectionĀ as attacks on automotive APIs climb within and among vehicle, cloud and mobileĀ  DALLAS and TOKYO, May 29, 2024ā€”VicOne, an automotive cybersecurity solutions leader, today announced a partnership with 42Crunch Ā to enhance the security of application programming […]

DataSheet

APIs are the core building block of every enterpriseā€™s digital strategy, yet they are also the number one attack surface for hackers. 42Crunch makes developersā€™ and security practitioners' lives easier by protecting APIs, with a platform that automates security into the API development pipeline and gives full oversight of security policy enforcement at every stage of the API lifecycle.

WEBINAR

Mitigate OWASP API risks through security-by-design

Learn best practices and mitigation steps for some of the OWASP API vulnerabilities through this 42Crunch API security best practice webinar
Nov 5, 2024
PST 9am | EST 12pm | GMT 5pm

NEWS

VicOne Partners with 42Crunch to Deliver Uniquely Comprehensive Security Across SDV and Connected-Vehicle Ecosystem

By Newsdesk | May 29, 2024

Collaboration pairs leaders in API and automotive cybersecurity to enable broad protectionĀ as attacks on automotive APIs climb within and among vehicle, cloud and mobileĀ  DALLAS and TOKYO, May 29, 2024ā€”VicOne, an automotive cybersecurity solutions leader, today announced a partnership with 42Crunch Ā to enhance the security of application programming […]

DataSheet

Datasheet Cover Images P1-02

Product Datasheet Addressing API Security Challenges

APIs are the core building block of every enterpriseā€™s digital strategy, yet they are also the number one attack surface for hackers. 42Crunch makes developersā€™ and security practitioners' lives easier by protecting APIs, with a platform that automates security into the API development pipeline and gives full oversight of security policy enforcement at every stage of the API lifecycle.

Ready to Learn More?

Developer-first solution for delivering API security as code.