When it comes to API hacking, fuzzing JSON payloads can expose some interesting security vulnerabilities.

One of my favorite reasons to fuzz JSON objects is it can usually lead to finding an entire class of vulnerabilities around “Mass Assignment”. This is where properties in a JSON object might be able to be tainted in a way that would allow us, as the attacker, to manipulate the data and possibly control the flow of execution within the API.

In this article, I will demonstrate how to do this. From creating a custom wordlist to optimize the fuzzing to automating the detection of a mass assignment vulnerability within Burp Suite, it should be fun.

Let’s get right to it.

Where to look for “Mass Assignment” vulnerabilities

The mechanics of finding where to look for mass assignment vulnerabilities is pretty straightforward. You want to analyze the API and look for endpoints that handle object/resource creation or updates, usually through POST, PUT, or PATCH requests. 

You want to look closely at the JSON payload sent in those requests. They may or may not represent known JSON schemas you encountered during recon of your API. 

It’s quite common for developers to use partial JSON objects. For example, an endpoint representing a user might include name, email, and password in the creation (POST), but only take the name and password in an update (PUT). Meanwhile, on the backend, the actual schema may look like this:

"User" : {
  "type" : "object",
  "properties" : {
    "email" : {
      "type" : "string"
    },
    "name" : {
      "type" : "string"
    },
    "password" : {
      "type" : "string"
    },
    "role" : {
      "type" : "string"
    }
  },
  "required" : [ "email" ]
}

When you see JSON objects used this way, you start to realize that endpoints that might accept additional properties could control how the API functions. For example, what would happen if we injected a “role” property in the PUT operation for the user resource? Could we elevate privileges?

Here is the rule: Track where resources are created and altered. Start by fuzzing the PUT and PATCH operations. They are the most likely places to trigger a mass assignment vulnerability. Then, check any place where a resource is created through a POST operation.

SIDE NOTE: Some developers use POST operations to update resources. So watch carefully to understand where endpoints are being used to create vs. update a resource. 

Attack the updates first. They are potentially the most vulnerable.

That’s a tall order since you might have dozens of different endpoints to check. Which is why we need to optimize our approach.

This is where a target-specific custom wordlist can help. 

Creating a custom wordlist

In a recent article I showed you how to fuzz for hidden API parameters using Burp Suite’s Param Miner extension. It will try to fuzz an endpoint using a dictionary of over 56,000 common parameters in its default configuration. This can literally take hours, if not days, to run against all the inputs, headers, and cookies on a target.

It’s just not practical to use for fuzzing JSON properties. At least, not without some optimization. 

Hence the custom wordlist.

In a perfect world, SecLists or AssetNotes would have already produced the perfect “JSON property keys” wordlist. But the reality is, it just doesn’t exist.

It would probably be huge and ineffective anyway.

So what do we do? We could use my guidance on using ‘cewl’ to generate a wordlist tailored to the client that connects to the API. But there is a better way—weaponizing the API documentation instead.

Parsing OAS for fun and profit

If you follow the latest specification for OpenAPI, you know that one component of an OAS document includes the schema that represents objects used for input and output to the API endpoints. This object is a superset of the JSON Schema Specification Draft 2020-12.

We can use that to our advantage. We can extract every known property in the API documentation and turn that into a custom JSON property keyword list.

Even better, I have already taught you how to do something like this when I showed you How to extract artifacts from OpenAPI docs to help attack APIs.

Yep, you only need jq to produce your custom wordlist tailored for your target API. **sweet**

Here is command that will do it:

cat your-oas-api-spec-doc.json | jq -r '.components.schemas.[].properties? | keys? | .[]' | sort -u > json-wordlist.txt

And with that we can now configure Param Miner to use this custom wordlist against any target endpoint we want and let Burp Suite fuzz it in the background.

Fuzzing JSON with Param Miner

If you recall from earlier in this article, you want to start by finding API endpoints that accept PUT or PATCH operations. When you find one in the Burp Proxy History, right-click on it, and select Extensions > Param Miner > Guess params > Guess JSON parameter.

If you don’t see a menu item to “Guess JSON parameter”, you aren’t looking at a request that includes a JSON payload.

In my case, I am going to fuzz a PUT operation on the /user/videos endpoint in the Completely Ridiculous API (crAPI). 

Param Miner will prompt you with an Attack Config dialog box. While in other articles I have told you to not modify the default settings; this is a time when you should. Specifically:

1. Uncheck “use basic wordlist”
2. Check “use custom wordlist”
3. Change the “custom wordlist path” to point to the newly generated custom wordlist you created for this target.

Now hit “OK”. Param Miner will immediately start fuzzing the endpoint. You can see the fuzzing attempts if you look in the Logger tab.

Don’t worry if you see Param Miner sending several other parameters. It also uses some of its heuristic capabilities to test several other ways to taint the data in an effort to detect the parameters. 

If anything is detected, you will see an Advisory published in the Issues section, and it will explain in the “Issue detail” what it found.

In my case, it found that a hidden parameter called “conversion_params” can be injected into the JSON payload when updating a video’s name.

This is a perfect example of a Mass Assignment vulnerability. But is it impactful? 

It ends up it is. I’ve actually covered why in my article on Tracing API exploitability through code review and taint analysis.

The data stored in “conversion_params” of a video is used when calling external video processing. You can taint that data and cause a command injection vulnerability that allows for complete remote code execution (RCE) on the API’s identity server through a separate SSRF vulnerability.

Attack chains for fun and profit. Gotta love them.  

And thanks to the fuzzing of the JSON payload, I found that mass assignment vulnerability early in the recon process.

YMMV, of course. But you can see how easy this is to do and how little effort is required.

Conclusion 

Fuzzing JSON payloads is a powerful technique for uncovering API security flaws, particularly mass assignment vulnerabilities. 

By targeting endpoints that handle object creation and updates, and leveraging tools like Burp Suite’s Param Miner with custom wordlists, you can efficiently identify hidden and undocumented JSON properties that may be abused.

This process not only exposes potential security weaknesses but also highlights the importance of thorough API documentation and robust input validation. As demonstrated, finding and exploiting these vulnerabilities can lead to significant security breaches, emphasizing the need for continuous and comprehensive security testing. 

With the right approach and tools, you can uncover these security flaws before your adversaries do.

HTH. 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. If you haven’t, subscribe today at https://apihacker.blog.

The post Fuzzing JSON to find API security flaws appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/fuzzing-json-to-find-api-security-flaws