Security testing guide for JSON / REST APIs #1/3

Ivan Novikov
Oct 16 · 2 min read

Fuzzing is everything ;) It’s the most useful and resultative hacking technique for sure. At the same time, fuzzing is not just random hitting applications or binaries with some random bytes.

It’s more about ideas, a deep understanding of data formats and application flows, technology stacks, and a lot of other things. It’s more about assumptions on how the particular application was designed and made, than random.

In these series of posts, I wanna share some experience on JSON fuzzing that I’ve achieved for the last 12 years of security audits.

Data types mutations

First of all, JSON is a serialization format, it’s not a string. It means, that you can play with data types even at the parser level. There are some data types available there:

  • string "string is here"
  • number 123
  • object {}
  • array []
  • boolean true
  • null null

This is the starting point for fuzzing. You should do all the data format mixes to check if it’s possible to cause some exceptions or unexpected behaviors.

For example, for an authentication token, which is a string by default, some of the following examples may give you some sugar:

{"authtoken": true, ...}
{"authtoken": [], ...}
{"authtoken": {}, ...}
{"authtoken": 0, ...}
{"authtoken": [true, "your-secret"], ...}

In a few words, if you know that some string will be compared with something inside an application logic, try to define it as boolean true, array or object to check type casting issue.

If you never saw type casting issues before, just run this PHP code in a command line:

$ php -r 'if("token"==0) echo "wtf";'
wtf

At the same time, a lot of application exceptions with some useful information could be obtained because of this issue. Simply because of that fact, that aimed application never expected array instead of string and so on.

Moreover, since some of the data types are recursive, as well as an entire JSON object, which an object type itself for sure, you can use similar ideas for DoS.

Usually, applications will use your data “as is” without any checks for their complexity. As a result, it’s possible to abuse loops there. If you know that some JSON parameters could be iterated inside an application logic, you can add some more data there.

The last thing I wanna mention here is numbers. I mean, It could be really big. Usually, it works for parameters likelimit, per_page, etc. Just to mention, the biggest number is 128, or 256 bits depends on the parser. So, you can check something like this:

{..., limit: 10e307}

That’s it for now. Next time I’ll explain some REST-related tricks.