Go Fuzz Yourself:

How to Find More Vulnerabilities in APIs Through

Fuzzing

Publication Information
Summary This white paper is sponsored
This white paper demystifies API Author Information by Detectify.
fuzzing, why it should be incorporated Alissa Valentina Knight
into every API penetration test, and Partner Initial Date of Publication:
what free, open source fuzzers are Knight Ink August 2021
available and how to use them. 1980 Festival Plaza Drive Revision: 1.0
Suite 300
Las Vegas, NV 89135
ak@[Link]
 2 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

TABLE OF CONTENTS

06 07 08
§ Key Takeaways § Introduction § Problem Statement
§ Audience § When penetration testing
doesn’t include fuzzing
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 3

TABLE OF CONTENTS

09 11 14
§ API Fuzzers § The OpenAPI Specification § Fuzzing with Kiterunner
§ Methods of Generating Input § HTTP Methods, Headers, and Values § Overview
§ Content Discovery § Replaying Requests
§ Send to Burp Suite
 4 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

TABLE OF CONTENTS

23 26 28
§ Wrestling with RESTler § Conclusion § Sources
§ About The Author
§ About Knight Ink
§ About Detectify
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 5

GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

6 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

KEY TAKEAWAYS

• Omitting fuzzing from your penetration testing other than a HTTP 403 or 404 error code
of APIs leaves vulnerabilities undetected that response from the EHR systems I was targeting
other tactics and techniques won’t find. in my vulnerability research campaign. When I
• Fuzz testing of APIs is setting the value of API finally did, it was a HTTP 200 and HTTP 415
operation parameters to a value that the response to a POST to an endpoint that I sent
developer didn’t expect to receive. to Burp and continued to manipulate within
• Because APIs process untrusted inputs, fuzzing Burp Repeater.
is fundamental to the penetration testing
process, often finding vulnerabilities missed by
static program analysis and manual code
inspection.
• Content discovery is the identification of
unlinked files and folders in a web application.
Specifically, when targeting APIs, it is an
effective tool when attempting to discover
undocumented API endpoints.
• API documentation is different from API
specifications, such as OpenAPI (formerly
Swagger). API documentation provides a
reference manual for both developers and non-
developers in how the API behaves and what
the expected inputs and responses are in plain
English.
• API specification files such as OpenAPI is a
format for describing an API, defining all its
available endpoints (such as /R4/patients) and
operations (such as PUT), supported
authentication methods, contact information,
and more. Currently at version 3, OpenAPI files
are clear text and written in specific languages,
such as YAML or JSON.
• HTTP verbs (methods) specifies a specific action
for the API endpoint to perform, such as GET,
POST (the most commonly used verbs), and for
REST APIs, PUT, PATCH, and DELETE. Each verb
corresponds to a particular action and expected
response code, such as 200 (OK). Meaning, the
action was performed successfully. 401
(Unauthorized) or 404 (Not Found), means the
file or resource doesn’t exist. Other response
codes exist, but these are the most common.
• Content discovery in APIs, specifically to the
end of discovering API endpoints requires
patience. It wasn’t until about two hours into
the scanning effort and attempting different
base URLs before I was able to get something
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 7

INTRODUCTION

Application programming interfaces (APIs) is Additionally, CISOs and other cybersecurity leaders
essentially a way to describe the protocols and can use this white paper to be better informed on
tools used for two systems to talk to each other — what their expectations should be of those
akin to a Rosetta Stone between applications that performing penetration tests of the APIs they are
allows them to talk that couldn’t previously responsible for securing and that the results of
understand each other without APIs. fuzzing are a fundamental part of the final report
delivered to them from the penetration tester(s)
A false sense of security is created when a Chief performing the work.
Information Security Officer (CISO) thinks her APIs
are secure simply because regular penetration
testing is performed. This false sense of security
can lead to an expensive data breach and loss to
customer and shareholder confidence.

An organization can think they’re secure because

penetration testing and vulnerability assessments
are being performed of their APIs, which can
include static and dynamic code analysis and
testing against the OWASP API Security Top 10.
But when the penetration tester doesn’t include
fuzzing in her testing, this can leave a number of
critical vulnerabilities undiscovered.

This white paper provides a deep-dive into what

API fuzzing is, what free, open source fuzzing tools
exist, how to use them, and more importantly,
how to interpret their results.

Consequently, this paper aims to inform CISOs and

other cybersecurity leaders on the criticality of
ensuring that penetration testers performing
testing of the APIs understand the profound
importance of incorporating fuzzing into their
tactics and techniques to ensure more thorough
and accurate results.

Audience
This paper was written for red team members who
want to learn how to properly perform
comprehensive penetration testing of their APIs by
incorporating fuzzing into their tactics and
techniques used in testing.
8 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

PROBLEM STATEMENT

Penetration testing of APIs performed today is SAST lacks context in security, meaning it doesn’t
profoundly inadequate if fuzzing isn’t performed understand how an API fulfills its contract or uses
as one of the tactics employed against the the data coming into it and is blind to third-party
endpoint. Many penetration testers don’t include libraries and frameworks where source code is
fuzzing in their repertoire of tactics and techniques typically not available. DAST was designed to send
either because: Web 1.0 style page parameter requests during the
running state of an application. DAST can not
1. They haven’t been exposed to fuzzing; invoke the API as it’s unaware of how to form the
2. Don’t know how to use fuzzing tools; or requests expected by the API endpoints. (Williams,
3. Don’t know how to properly interpret the J., 2015)
results.
API Fuzzers
This creates a false sense of security with the There are different taxonomies of fuzzers that
organization thinking all possible vulnerabilities leverage different techniques towards the same
were found for remediation, leaving potentially goal. While different people opine on what these
vulnerable APIs exposed to the internet. categories of fuzzers are, it’s generally accepted
that Microsoft’s taxonomy makes the most sense.
These include:

• Knowledge of Input;
• Knowledge of target application structure; and
• Method of generating new input.

Knowledge of Input
When Penetration Testing This category of fuzzers are also referred to as
Doesn’t Include Fuzzing “smart fuzzers” as they have a knowledge of the
application’s expected input and format. For
example, the encoding expected such as Base64 or
Vulnerability Scanners
Approaching penetration testing of web file-type, such as PE headers.
applications can be done using manual testing of
vulnerabilities in the OWASP Security Top 10, such Knowledge of Target Application Structure
Before I decompose the different taxonomies of
as SQL injection, cross-site scripting (XSS), and
fuzzers, it’s important to note that in the broader
more; and automated scanning using tools, but
these same scanners can’t be used to find hemisphere of testing is black box and white box
testing. In lay terms, white box testing is simply
vulnerabilities in APIs due to the nature of how
different APIs work from traditional web apps. where the tester or the tool has the requisite
information needed of the target that obviates the
need to figure it out (a la guessing) while black box
There are two types of approaches to identifying
vulnerabilities in applications, static application testing is the antithesis of that, ultimately
requiring the tester or the tool to figure it out on
security tools (SAST) and dynamic application
security tools (DAST). These scanners approach their own by hunting for the answers to those
questions.
vulnerability identification differently.

SAST performs what’s also referred to as “static In the application of fuzzers, the smartest fuzzers
will have full (white box) or partial (gray box)
code analysis” where the source code is checked
line-by-line for vulnerabilities, often responsible information on the target API.
for a lot of false positives.
 HACKING APIS THROUGH FUZZING AND CONTENT DISCOVERY 9

API
FUZZERS
GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH
10 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

API FUZZERS

Method of Generating New Input search for files and folders of interest typically
Fuzzers are capable of generating the test input placed there with the different API frameworks.
data from scratch randomly or semi-randomly or
by taking pre-existing properly structured stimulus Routes and Endpoints
by mutating it to generate different permutations In traditional web applications, filenames and
for stimulus to evaluate how the target application folders are mapped to actual files and folders that
responds. exist on the web server, e.g.
[Link] which actually
This paper demonstrates the efficacy of two maps to a file on the web server called [Link].
different types of fuzzers, Kiterunner and RESTler However, in modern web applications, such as
and decomposes the idiosyncratic distinctions APIs, you’ll have a server
between them through the presentation of their [Link] which specifies a
empirical output run against public APIs. route. On the server is a routes file that points to a
snippit of code instead of an actual file. In the
Fuzzing should be used because it’s an effective latter example URI, /r4 is the API endpoint.
way to find security vulnerabilities in applications.

According to Microsoft, thousands of

vulnerabilities have been discovered as a result of
fuzzing. Fuzzing has become so critical to the
software development life cycle (SDLC) that
Microsoft requires it as part of its Microsoft
Security Development Lifecycle for every
untrusted interface.

Content Discovery
Content discovery is the automated identification
of hidden/unlinked resources that aren’t visible or
able to be spidered in a target web application.
While content discovery tools date back several
decades, this class of tools have continued to
evolve from Web 1.0 to modern applications, such
as APIs to become more context-aware.

Content discovery is performed differently across

different tools, such as Burp suite, which uses
name guessing, web crawling, and extrapolation
from naming conventions. Traditional content
discovery tools simply look through a wordfile to
find files or folders that might exist on the target
web server. Newer content discovery tools have
evolved to enable targeting of modern web
applications such as APIs. Many content discovery
tools are now specifically made for RESTful APIs
using openAPI (formerly Swagger) files in order to
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 11

THE OPENAPI
SPECIFICATION

GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

12 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

The OpenAPI Specification 2019).

Originally called Swagger specification, OpenAPI
specification is a format for describing an API, The OpenAPI specification should come first and
defining all of its available endpoints (such as can generate the documentation for the API, but it
/R4/patients) and operations (such as PUT), can go further than that, including generating a
supported authentication methods, contact mock server, the stubs of the API for publishing,
information, and more. Currently at version 3, the SDK for the different stacks for creating the
OpenAPI files are clear text and written in specific API consumers from a single source of truth.
languages, such as YAML or JSON.

An OpenAPI spec can produce documentation for

an API so that anyone, even non-developers can
understand what the API is for, how to access it,
what the expected inputs and outputs are, and
more in plain english.

In summary, the OpenAPI interface-description

language for REST APIs has largely become the
most popular specification for describing how to
access a cloud service through its REST API that
details what requests it can handle, what
responses may be received, and the response
format (Atlidakas, V, Godefrroid, P, Polishchuk, M,

Figure 1. Sample OpenAPI File

Source: Knight Ink

 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 13

HTTP Methods, Headers, and Values

HTTP headers are options that can be passed along
from an HTTP client to an HTTP server (web server)
or visa-versa from an HTTP server to a client.

These values can contain a number of different

options. The different header types include
request headers, response headers,
representation headers, and payload headers.
Header options can include values, such as
Authorization, which contains authentication
credentials; or a cookie header, which can contain
a stored HTTP cookie that the server uses to
identify an already authenticated user/session. See
Figure 2 below for a sample.

HTTP verbs (methods) specify a specific action for

the API endpoint to perform, such as GET, POST
(the most commonly used verbs), and for REST
APIs, PUT, PATCH, and DELETE. Each verb
corresponds to a particular action and expected
response code, such as 200 (OK), meaning the
action was performed successfully; 401
(Unauthorized), or 404 (Not Found), meaning the
file or resources doesn’t exist. Other response
codes exist, but these are the most common.

HTTP parameters are the variable part of a

resource that determine the type of action you
want to take. These are passed as options to the
endpoint in order to elicit a specific response, such
as header parameters, query parameters, and so-
on.
Figure 2. Sample OpenAPI File

Source: Knight Ink

 14 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

Fuzzing
WITH KITERUNNER
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 15

CONTENT DISCOVERY WITH KITERUNNER

Overview
In this section, I present a real-life use case of
Kiterunner employed against public APIs. The
empirical data presented in this paper underscores
the importance of running content discovery tools
against APIs in order to find unlinked files and
folders accessible via the API. Additionally, this
paper provides prescriptive step-by-step use cases
of how to use Kiterunner against API endpoints
and the results that specific stimulus generated by
Kiterunner provides.

Kiterunner is a tool for performing forced

browsing, checking for accessibility to unlinked
files or folders that aren’t directly referenced in
the web application but available to adversaries.
Kiterunner doesn’t simply guess for random
permutations of different files and folders. Its
creator, Shubham Shah, codified over 67,000
different openAPI files he gathered across the
internet that Kiterunner uses for its checks that
can be typically found in APIs generated by off-
the-shelf frameworks like Flask, Rails, and Express.

Kiterunner’s braintrust is built around how APIs

are built by using these openAPI files instead of
just random brute forcing.

Content discovery is the use of an automated tool

targeted at web servers that typically uses a flat
textfile of folders and filenames that it cycles
through in order to find files and folders in the
“web root” of the server.

Installing Kiterunner (Mac)

$ brew install go
$ sudo apt install golang-go
16 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

Linux

# build the binary

make build

# symlink your binary

ln -s $(pwd)/dist/kr /usr/local/bin/kr

# compile the wordlist

# kr kb compile <[Link]> <[Link]>
kr kb compile [Link] [Link]

# scan away
kr scan [Link] -w [Link] -x 20 -j 100 --ignore-length=1053

Running with Kites access token and ships in the form of a JSON
1. Download large and small wordlists (.kite files) object.
from the Kiterunner Github page
The JSON datasets can be found below: If the API has implemented tokens, you’ll need to
• [Link] (118MB compressed, authenticate with the API using the Chromium
2.6GB decompressed) browser within Burp Suite for example, then copy
• [Link] (14MB compressed, and paste the token you receive into your
228MB decompressed) command line for Kiterunner in order to send
authenticated requests to the API. Otherwise, not
Alternatively, it is possible to download the doing so will result in a bunch of HTTP 403
compile .kite files from the links below: (FORBIDDEN) error messages rendering your
• [Link] (40MB compressed, 183M Kiterunner scan useless.
decompressed)
• [Link] (2MB compressed, 35MB In order to pass fields to the header of your
decompressed) requests within Kiterunner, pass the -H flag to
Kiterunner and specify your header fields, in our
2. kr scan [Link] -w [Link] case, the Bearer token between quotes. (Figure 3).

Tokens: Modifying Your Header

Hopefully, the API you’re targeting has
implemented bearer tokens and is using tokens for
authentication and scopes for authorization. If the
API has implemented a Bearer token, it could be a
random string of characters or a JSON Web Token
(JWT), which encodes the access token into an
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 17

Figure 3: Virtual application path based routing illustration

Source: Knight Ink

Kiterunner in the Weeds By default, when depth isn’t specified, Kiterunner

Depth Scanning will scan a target at 1 level deep, meaning if you
A particularly powerful feature of Kiterunner is its specified a target of [Link], Kiterunner would
ability to define how many levels deep within the scan [Link]/api.
folder structure a scan should be performed of a
path, especially useful in path-based routing At level 2, it would scan [Link]/api/R4 and at
(Figure 4). level 3, it would scan [Link]/api/R4/patient.

Path-based routing is simply being able to route

traffic to backend servers based on paths defined
in the API request. For example,
[Link]/images could be routed to a backend
images server farm or [Link]/patients could
be routed to servers designed specifically for
holding patient EHRs.
18 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

Figure 4: Virtual application path-based routing illustration

Source: Knight Ink

Assetnote Wordlists The wordlists from [Link] are quite large. If

Wordlists are flat files of common paths found in you don’t want to use the entire wordlist, you
web applications and are used by many of the have an option you can pass Kiterunner when
popular content discovery tools, such as Dirbuster. starting the tool that will tell it to only use the first
X number of lines that you specify and then
However, Assetnote culls together and updates gracefully stop.
their wordlists from Swagger files collected from
across the internet on the 28th of each month For example, as shown in the documentation, if
giving you the richest dataset of wordlists you want to only use the first 20,000 lines of the
specifically designed for APIs than any other tool. API routes wordlist:

When wordlists are compiled from .txt files into # this will use the first 20000 lines in the api routes
.kite files, they are cached in wordlist
~/.cache/kiterunner/wordlists. An example of one
of the wordlists from the most recent list of $ kr scan <target> -A=apiroutes-
generated wordlists on [Link] can be found 210228:20000 -x 10 --ignore-length=34
in Figure 5 below.

However, unless you know for sure you don’t want

to use the latter portion of a wordlist, this can
cause you to miss findings so use with caution
knowing you may miss something.
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 19

Figure 5: Recent entries from Kiterunner’s generated wordlists

Source: Knight Ink

20 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

Replaying Requests Send to Burp Suite

Kiterunner’s output doesn’t provide much utility Kiterunner has the ability to send all of its requests
beyond seeing the HTTP response code for the that you replay through a proxy server for further
HTTP requests sent by Kiterunner. You’ll need to manipulation instead of using Kiterunner’s replay
dig further into the actual request to better option at the command line.
understand what was sent and what was received
back from the API. By sending everything through Burp’s Proxy, you
have the ability to interdict every API request and
This requires use of the replay option in analyze the stimulus and response in intercept and
Kiterunner. Replay will replay a specific API forward it on or replay it with different
request sent from the previous or currently permutations of the original request (Figure 6).
running session.

$ kr kb replay -w <wordlist> “GET 400 [ 311,

18, 7] [Link]
oauth/api/FHIR/R4/v1/book
0cf6832e5e4c0aa6b0f5e513fd0c85708446cda0
”

Figure 6: Using Kiterunner replay to dig further into an HTTP response from the FHIR API server

Source: Knight Ink

 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 21

To do this, you’ll need to enable the proxy within

Burp, disable intercept, then add the --proxy
option to Kiterunner when running it.

This will force Kiterunner to send all of its requests

and the responses will then be captured within
Burp.

Steps to send Kiterunner through Burp’s proxy:

1. Find IP/PORT Burp is listening on

2. Turn off intercept
3. Append --proxy=[Link] to
Kiterunner
4. View request in Burp’s HTTP history window

Figure 7: Analyzing Kiterunner replays within Burp Suite

Source: Knight Ink

22 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

Figure 8. Sending a HTTP 415 response code to Repeater in Burp for further tampering

Source: Knight Ink

 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 23

WRESTLING
WITH RESTler
GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH
24 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

WRESTLING WITH
RESTler
RESTler, developed at Microsoft, is the world’s first 2. First, create the directory where you’ll be
stateful API fuzzer that automatically generates building RESTler
tests and automatic execution by first reading the 3. Switch to the repo root directory and run the
OpenAPI specification in order to automatically following Python script:
find vulnerabilities in the API.
$ python ./[Link] --dest_dir
A high-level picture for the first-time usage of <full_path_to_directory_you_created_in_st
RESTler can be found in Figure 9 below. ep_2>

Building RESTler
The following section is adapted from the build NOTE: If you receive a nuget error NU1403 when
instructions available on the Github repository for building, a quick workaround is to clear your cache
RESTler. with this command: $ dotnet nuget locals all--clear

1. The prerequisites for installing RESTler are

Python 3.8.2 and .Net 5.0. Currently, RESTler
supports Windows and Linux on 64-bit
machines but has experimental support for
macOS.

Figure 9. RESTler high-level flow for first-time usage

Source: Microsoft
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 25

The below results are typical for an API that does An optional settings file can also be passed to
not require authentication and has a few GET RESTler by adding the command-line option --
endpoints without any input parameters. settings <path_to_settings_file.json>. For a list of
available settings, see SettingsFile.
• 29 requests (endpoint + method) were found in
the Swagger spec. Outputs: see the sub-directory FuzzLean or Fuzz
• 3 requests were attempted by RESTler. The (similar to Test)
other 26 were not attempted because RESTler
determined that they depend on outputs of RESTLer will generate a sub-directory
one of the requests that were executed, and a Fuzz[Lean]\RestlerResults\experiment<GUID>\logs
failure prevented that output resource from including the following files:
being available to the other requests.
• 2 requests were successful. • bug_buckets.txt reports bugs found by RESTler.
• The coverage is 7% (2/29) Those bugs are either "500 Internal Server
• There were no bugs found. Sometimes, bugs Errors" found by the RESTler "main_driver" or
are found in the quick start phase. property checker violations

RESTler currently detects these different types of

In Fuzz-lean mode, RESTler executes once every bugs:
endpoint+method in a compiled RESTler grammar
with a default set of checkers to see if bugs can be • "500 Internal Server Errors" and any other 5xx
found quickly. errors are detected by the "main_driver"
• UseAfterFreeChecker detects that a deleted
In Fuzz mode, RESTler will fuzz the service under resource can still being accessed after deletion
test during a longer period of time with the goal of • NameSpaceRuleChecker detects that an
finding more bugs and issues (resource leaks, perf unauthorized user can access service resources
degradation, backend corruptions, etc.). Warning: • ResourceHierarchyChecker detects that a child
The Fuzz mode is the more aggressive and may resource can be accessed from a non-parent
create outages in the service under test if the resource
service is poorly implemented. • LeakageRuleChecker detects that a failed
resource creation leaks data in subsequent
$ [Link] fuzz-lean --grammar_file requests
<RESTLer [Link] file> --dictionary_file • InvalidDynamicObjectChecker detects 500
<RESTler [Link] file> -- errors or unexpected success status codes
token_refresh_interval <time in seconds> -- when invalid dynamic objects are sent in
token_refresh_command <command> requests
• PayloadBodyChecker detects 500 errors when
$ [Link] fuzz --grammar_file <RESTLer fuzzing the JSON bodies of requests
[Link] file> --dictionary_file <RESTler
[Link] file> -- RESTler will also generate a sub-directory
token_refresh_interval <time in seconds> -- Fuzz\ResponseBuckets including the following
token_refresh_command <command> -- files:
time_budget <max number of hours
(default 1) • [Link] is a report on all the HTTP
error response codes that were received
• [Link] includes a sample of up to 10
pairs of <request, response> for each HTTP
error codes in the 4xx or 5xx ranges that were
received
26 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

CONCLUSION
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 27

Conclusion
I have performed dozens of penetration tests of
APIs in my career, from hacking healthcare APIs to
hacking federal and state law enforcement
vehicles through the manufacturer’s APIs giving
me remote control of the vehicles.

In every penetration test I’ve performed, fuzzing

has always been the most profoundly important
step of the tactics and techniques I use in my kill
chain to find vulnerabilities that only fuzzing can
find.

Manipulation of parameters, especially when

dealing with hundreds in large scale deployments
of API endpoints can and should only be done with
an automated fuzzing tool.

If you have the distinct feeling that you may have

missed vulnerabilities in your API penetration test,
it’s most likely because you didn’t perform any
fuzzing of the target endpoints.

In this paper, I demystified API fuzzing, explained

the different type of API fuzzers among the more
popular options and explained their usage and
how to interpret their results.

I used Kiterunner, my go-to open source fuzzer for

performing an API penetration test against real-
world APIs and explained how to point it at Burp
Suite for further replay attacks, extending
Kiterunner’s capabilities with those offered by
Burp Suite.

It’s my belief that a penetration test of an API that

doesn’t incorporate fuzzing in the tactics and
techniques used by the penetration tester is
consequently incomplete until fuzzing has been
performed.
28 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

SOURCES
Assetnote. (n.d.). assetnote/kiterunner. GitHub. Retrieved June 22, 2021, from
[Link]

OWASP. (n.d.). Forced Browsing Software Attack | OWASP Foundation. Retrieved June
22, 2021, from [Link]

Li, V. (2020, January 26). Fuzzing Web Applications - The Startup. Medium.
[Link]
14a8b702dc61-1624248014&_branch_match_id=link-935370843063544148

RapidAPI. (2021, April 20). What is an API Endpoint? | API Endpoint Definition |
RapidAPI. The Last Call - RapidAPI Blog. [Link]
glossary/endpoint/

Swagger. (n.d.). About Swagger Specification | Documentation | Swagger. Swagger

Specification. Retrieved June 22, 2021, from
[Link]

OpenAPI. (n.d.). OAI/OpenAPI-Specification. OpenAPI Specification - GitHub. Retrieved

June 22, 2021, from [Link]
Specification/blob/main/versions/[Link]

Todd Fredrich, Pearson eCollege. (n.d.). HTTP Methods for RESTful Services. Pearson
ECollege. Retrieved June 22, 2021, from
[Link]

RapidAPI. (2021b, April 23). What are API Parameters? | Parameters Definition | API
Glossary. The Last Call - RapidAPI Blog. [Link]
glossary/parameters/

Paxton-Fear, D. K. P.-F. (2021, April 14). API Recon with Kiterunner - Hacker Toolbox.
YouTube. [Link]

Swagger. (n.d.-b). Understanding the Differences Between API Documentation,

Specifications, and Definitions. Retrieved June 22, 2021, from
[Link]
specification/

Our guide to fuzzing | F-Secure. (n.d.). F-Secure. Retrieved August 12, 2021, from
[Link]

Godefroid, P. (2020, March 4). A brief introduction to fuzzing and why it’s an important
tool for developers. Microsoft Research. [Link]
us/research/blog/a-brief-introduction-to-fuzzing-and-why-its-an-important-tool-for-
developers/
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 29

Williams, J. (2015, June 25). What Do You Mean My Security Tools Don’t Work on
APIs?!! Dark Reading. [Link]
you-mean-my-security-tools-don-t-work-on-apis-

Licata, S. (2020, June 19). Focus on Fuzzing: Types of Fuzzing. SAFECode.

[Link]

Web API Fuzz Testing | GitLab. (n.d.). Gitlab. Retrieved August 12, 2021, from
[Link]

GitHub - microsoft/restler-fuzzer: RESTler is the first stateful REST API fuzzing tool for
automatically testing cloud services through their REST APIs and finding security and
reliability bugs in these services. (n.d.). GitHub. Retrieved August 13, 2021, from
[Link]

[Link]
30 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

ABOUT THE AUTHOR

Alissa Knight is a partner at Knight Ink and

blends influencer marketing, content
creation in writing and video production,
go-to market strategies, and strategic
planning for telling brand stories at scale
in cybersecurity.

She achieves this through ideation to

execution of content strategy,
storytelling, and execution of influencer
marketing strategies that take
cybersecurity buyers through a brand’s
custom curated journey to attract and
retain them as long-term partners.

Alissa is a published author, having

published the first book on hacking
connected cars and is working on a new
series of books into hacking and securing
APIs and microservices.
 HOW TO FIND MORE VULNERABILITIES IN APIS THROUGH FUZZING 31

ABOUT KNIGHT INK

Firm Overview We work with our customers to create a

Knight Ink is a content strategy, creation, content strategy built around their blue
and influencer marketing agency founded ocean then perform the tactical steps
for category leaders and challenger necessary to execute on that strategy
brands in cybersecurity to fill current through the creation of written and visual
gaps in content and community content assets unique to the company
management. We help vendors create and its story for the individual customer
and distribute their stories to the market personas created in the strategy setting.
in the form of written and visual
storytelling drawn from 20+ years of
experience working with global brands in Contact Us
cybersecurity. Knight Ink balances Web: [Link]
pragmatism with thought leadership and Phone: (702) 637-8297
community management that amplifies a Address: 1980 Festival Plaza Drive, Suite
brand’s reach, breeds customer delight 300, Las Vegas, NV 89135
and loyalty, and delivers creative
experiences in written and visual content
in cybersecurity.

Amid a sea of monotony, we help

cybersecurity vendors unfurl, ascertain,
and unfetter truly distinct positioning
that drives accretive growth through
amplified reach and customer loyalty
using written and visual experiences.

Knight Ink delivers written and visual

content through a blue ocean strategy
tailored to specific brands. Whether it’s a
firewall, network threat analytics
solutions, endpoint detection and
response, or any other technology, every
brand must swim out of a red sea of
competition clawing at each other for
market share using commoditized
features. We help our clients navigate to
blue ocean where the lowest price or
most features don’t matter.
32 GO FUZZ YOURSELF | BROUGHT TO YOU IN PARTNERSHIP WITH

ABOUT DETECTIFY

Firm Overview
Detectify offers cloud-based web
application security solutions that
streamline vulnerability findings in
production to security defenders and
application owners. Detectify
collaborates with ethical hackers to
source the latest security research from
hacker-into-scanner in as fast as 15
minutes. It leverages fuzzing and crawling
techniques and delivers reliable payload-
based testing to customers. This means
verified results and clearer visibility with
less noise. With Detectify you will bring
security up to speed and scale with
development, and go to market safer.

Curious to see what Detectify will find in

your websites? Head over to
[Link] to start a free 2-week
trial!
Knight Ink
1980 Festival Plaza Drive
Suite 300
Las Vegas, NV 89135
ak@[Link]