We’ll be using a specific library for mine called FSecurity. This library contains several building blocks that makes security testing a more fun process. Just like my other library FScenario is about making integration tests a less painfull process.
Besides API testing, it contains other useful components as well but I will not discuss them here:
The library that I will discuss is called FSecurity.Api.
Creating a HTTP request template
When interacting with an API component, one has to create a HTTP request, which could entail required headers, parameters and so on. In our security tests, we’ll call this the ‘request template’.
This template will not contain what we want to test or the ‘injection point’ of the test.
Here’s an example of how such a template is created using the library:
The request template can be created with additional Req.parameter‘s, Req.header‘s, Req.clientCertificate… This template model will later be converted to a full HttpRequestMessage when the API security test will run.
Request injection points
During the request template creation, you’ll have to make a choice which part of the request you want to test. In one test you can choose to test a certain header that the API takes as input, in another it could be a parameter or a part of the body.
If you have chosen the part of the request you want to test, you can start thinking about what values it should test against. Numbers? Special characters? Emoticons? Alphanumerics? And also how long each input should be. 5 characters? 10? maybe 10.000?
The library contains a Fuzz type that contains all sorts of inputs that you can use directly in your test. You can of course use your own stream of strings that you add as a resource text file to your test project.
Determining vulnerability
When you have your request template, and you know where and what you want to test, you’re ready to define which cases of the response of the API can be considered a vulnerability. If for example, during input validation an invalid model is sent to the API and the API responds with a 200 OK, you can assume that this is at least incorrectly implemented and possibly vulnerable to injection (although this depends on implementation of course).
The library models these vulnerabilities in a Vulnerability type that contains the severity, description, and response content so it can be reported to the test report.
Of course, unlike in the example below, you will be able to have access to the HTTP response and injection payloads so you can just pass it along during the creation of the vulnerability value.
API vulnerability scanning with injection payloads in request template
Now we have all the building blocks to scan our API service on security vulnerabilities: request template, injection points, and vulnerability determination.
The library provides a Api type that will be the starting point for our security test. The previously explained concepts can all be combined by calling the correct function on the type.
Api.injectallows you to register the injection payloads you want to use in the current test.Api.intoallows you to specify where the injection payloads should be inserted in the HTTP request.Api.should*allows you to specify one ore more assertions when a HTTP response is considered invalid and/or vulnerable; it allows you to create the vulnerability right away.Api.scantakes in the request template and returns the set of vulnerabilities it has found accourding to the above specification.
The following example shows how this can be combined.
Note that Req.contentType is a shorthand to create a function that alters the request’s content-type with another value.
Note that Res.status is a shorthand to create a function that returns a Vulnerability when the response doesn’t have the expected status code.
And of course I haven’t forgotton about the non-F# devs. The library contains all the necessary extensions to have the same functionality in C# as well.
Conclusion
One of the reasons I think why application security is overlooked, is that the tools and information is not yet structured in this way. Even in college, application security is as far as I know, not yet a major part of the curriculum during software development. In previous posts, I’ve talked about Domain-Driven Security with specifications and access control and about how you receive untrusted input and map it into a secure model. Now, I’m giving you the tools to test such models and many other possible security scenarios in your application.
Now, more than ever, is the time to take application security serious and make it an obvious task when writing your integration tests.
Thanks for reading and good luck!
Stijn
Subscribe to our RSS feed