You are here

How to hack your web API with negative testing

Morgan Roman, Software Security Engineer, DocuSign

Software may be taking over the world, but web APIs are taking over software. Behind nearly every SaaS product and web application is a web API. These APIs control everything from your banking transactions to which videos you like.

So if you are building an API, you need to prevent both security breaches of customer data and getting "pwned" by hackers. One of the simplest ways to quickly find security vulnerabilities before hackers do is to take your existing API tests and turn them into security tests.

There are two kinds of negative-test strategies for this: injection and scrambling. To try this, you'll need a web API and some API testing experience with Postman, which is the Google Chrome app for interacting with HTTP APIs, or any other framework. 

It doesn't matter if your API is written in JSON, SOAP, or something else. But note that most tests are positive tests, because you want to ensure that the features positively exist and work. Instead, this strategy uses negative tests, which ensure that unwanted features don't exist and someone can't hack the application.

Here's how to bolster the security of your web APIs—and your software overall—with negative testing.

[ Get up to speed fast on today's tools with TechBeacon's Application Security Buyer's Guide 2019 ]

Injection testing

Injection involves replacing something that you would normally use as test input with an example payload. For example, instead of naming your test user "Tester McGee," you look for SQL injection by finding a SQL injection payload from OWASP and name your test user "admin." You can also use any other SQL injection code you can find in a cheat sheet.

You can use this method for many attacks, such as SQL injection, XXE, and regex denial of service.

Let's dive into a specific test of a sample note taking application:

This test’s steps are:

  • Alice creates a profile.
  • Alice logs in.
  • Alice creates a note.
  • Alice views the note.

Now let's figure out places in that test to use injection.

  • Alice creates a profile. At this point, you can try to inject payloads into Alice’s name/address/password.
  • Alice logs in. You could have the test attempt long passwords looking for ReDoS.
  • Alice creates a note. You could attempt to make the note contents contain malicious XML or SQL injection.
  • Alice views the note.

Essentially, at any point you provide fake user input during the test, you can make that input malicious, and if the test fails, since it cannot load properly, or if the test assertions fail, then you might have a security bug.

In the case of SQL injection or ReDoS, simply allowing the test to fail is a good way to detect a security vulnerability. For XML external entity injection, you can also have your payload reach out to an external endpoint or read a file to help you detect a vulnerability.

[ Application layer attacks are on the rise. Get key takeaways from the 2019 Application Security Risk Report in this free Sept. 25 webinar ]

Scrambling the steps

The next method for finding security bugs is what I call "scrambling." This involves mixing up or removing steps in a test, or who makes each call in the test, with the expectation that the test will fail. Use this method to find business logic bugs in authorization.

For example take the following example test for our note-taking application:

  • Alice creates a note and gets an ID for the note.
  • Alice views the note using the ID.
  • Alice modifies the note using the ID.
  • Alice shares the note with Bob using the ID.
  • Bob views the note using the ID.

Let's modify our test to check that Alice actually needs to share the note with Bob for him to see it:

  • Alice creates a note and gets an ID for the note. You need to leave this step alone as your "setup" step.
  • Bob views the note using the ID. You can make sure Bob cannot see the note before sharing.
  • Bob then modifies the note using the ID. You can ensure that Bob can't modify notes that he cannot see.
  • Bob then shares the note with Bob using the ID. Make sure Bob can't share Alice’s note with himself.
  • Bob views the note using the ID. Check that your previous actions didn’t change the state.

This above test should fail. It also checks for  Insecure Direct Object Reference (IDOR) attacks, assuming that Bob could guess the note's ID (we could assume it is not secret or easy to guess). This test can now be part of your CI/CD pipeline, and run automatically.

The power of this method

Use this technique and you'll find more bugs than you will using most DAST tools, since those lack context on how to use the product, and often fail at doing any multi-step flow.

To get started, validate whether a security bug that your team has already fixed is still fixed. In this way you can run this constantly, on every deploy, to ensure that dangerous security bugs stay fixed in your API.

Don't miss my talk, "Ban footguns: How to standardize how your developers use dangerous aspects of your framework," at DevSecCon Seattle. The conference runs September 16-17, 2019.
