Exploiting an API with Structured Format Injection

Never trust user input.

It’s been the mantra for years in popular secure coding books.

Yet, even today, we continue to see abuse of tainted data taking out the apps and infrastructure we use daily.

While input validation is improving in frontend web apps, it’s not uncommon to bypass this altogether and go straight to attacking the APIs.

Why does this work so well? It’s all because APIs use structured data formats like JSON and XML, which developers trust implicitly.

When structured data is being relied on, such as within API contracts, Structured Format Injection (SFI) becomes a thing.

SFI allows an attacker to manipulate the structure of the data being transferred between systems in order to exploit vulnerabilities and gain unauthorized access.

Today, I am going to show you how to do just that.

Exploiting APIs with SFI

To exploit an API with SFI, you first need to identify the data format being used.

This can usually be done by inspecting the requests and responses between the client and server using a proxy or network analysis tool like Burp Suite. Even better, the API spec docs should showcase what object models it may be expecting.

Of course, if you don’t have access to detailed documentation, you can generate your own rogue docs from the traffic you record while using the API.

Once the data format is identified, you can manipulate its structure to carry out your attack.

For example, you could add additional fields or values to bypass authentication checks, inject malicious code, or modify existing data to change the behavior of the application.

In this article, I want to focus on injecting malicious input that may cause the API on the server to behave differently by polluting parameters.

This is sometimes called Server Side Parameter Pollution (SSPP).

Server Side Parameter Pollution

It isn’t uncommon to find API endpoints that are used to do partial updates to a data record.

Imagine you have a database that includes a Users table. The table consists of the following columns:

• id
• name
• email
• password
• role

It seems harmless enough.

That role field looks interesting. During recon, you notice it can be either “user” or “admin”, depending on the security context you are in.

Now imagine the frontend web UI exposes a link in your profile that allows you to “Change Display Name”. When clicked, it exposes to you a single text field to change your display name.

When you hit submit, you see the following request to the server:

POST /myprofile
Content-Type: application/x-www-form-urlencoded

name=Dana

Looks pretty straightforward.

It’s clear that this request does not represent the actual User object that reflects the database structure. So there is a good chance the developers are receiving this request and parsing out the field.

This is actually a best practice recommendation developers are told to use to prevent things like Mass Assignment vulnerabilities.

But is it enough? Not really.

You may be able to manipulate parameters to exploit vulnerabilities in the server’s structured data processing. Since developers usually take this data and serialize it directly into an object, it may very well let you inject additional parameters it isn’t expecting.

To test for this, inject unexpected structured data into user inputs and see how the server responds.

Example of Structured Format Injection Abuse

Consider this example payload for the endpoint talked about previously:

name=Dana","role":"admin

Now imagine that the server processes this data to call the backend server API that you don’t have direct access to. It might look something like this:

PUT /api/users/1234

{"name"="Dana","role":"admin"}

Did you see what happened here? I tried to bold the payload to show the construction on the JSON object that was sent to the backend API, but it doesn’t work well. Notice though how the “name” is escaped properly in the object, and the name payload is escaped allowing for the role property to now be included.

While we could not directly update the user, we still exploited a Broken Object Property Level Authorization vulnerability to give ourselves the admin role by using SFI.

When software frameworks automatically bind request parameters to fields on an internal object, it can lead to hidden parameters in an API that developers didn’t even intend to allow to be read or written.

This is sometimes called auto-binding. It’s a real problem for devs but a real opportunity for us.

A Second Example of SFI Abuse

You already know I am a big fan of tainting data in weird places. One great place is to manipulate the Content-Type and see if the API might act differently.

So consider the previous example. How could we possibly cause a different interaction? How about forcing the parameter pollution right in the first request by forcing a JSON object to be sent instead of raw form data?

POST /myprofile
Content-Type: application/json

{"name"="Dana\",\"role\":\"admin"}

Notice the backslashes escaping the double quotes inside the JSON object? That allows enough encoding that it will pass the POST request and allow processing by the backend.

Depending on how the server processes the request and creates the JSON object going to the backend API, it may inject the role property and ultimately give you admin access. 😈

A side benefit of this approach is that it may bypass other input filters the backend may otherwise process differently and allow for more complex tampering of multiple fields simultaneously.

YMMV. Every API is going to act differently… but you get the general approach now.

Conclusion

Do you see how Structured Format Injection (SFI) can be your friend?

Through Server Side Parameter Pollution, it may be possible to abuse an API and find Broken Object Property Level Authorization (BOPLA) vulnerabilities. All by adjusting your payloads to inject malicious input that may “restructure” the JSON objects behind the scenes.

In other words, try to taint all the things.

You’d be surprised what you might end up finding.

Good luck!

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. Subscribe at https://apihacker.blog.