Security testing
The testing strategy that comes closest to security testing is stress testing. You test your project under abnormal circumstances and verify if the project is still acting as expected.
Security testing changes the input values in such a way that the output could be unexpected. Input injection is a good example of this. For example, you can stress-test it by overwhelming the system with inputs, and then security-test it by inputting an injection string to see if there’s a misuse of a parser.
Property-Based Testing
Testing properties is a different approach to how we can test functionality. With this approach we manipulate the input in such a way that we can predict the output without specifying the input or output.
Property-based testing is a major topic that I can’t cover in this one short post. If you want to learn more check out the F# package in the documentation over at FsCheck.
Be sure to take a look at the two posts I’ve written on this topic previously:
Introducing FSec
I wanted to find a way to combine both the security aspect and property-based testing. I knew that it would need to have input generators that can do things like generating different kinds of “injection” inputs so that we can verify if we’re vulnerable to security attacks.
So I started working on a package called FSec which provides input generators for security testing and can also be used in property tests.
The package is written in F# but has also a C# friendly API. I recommend that you brush up on Property-Based Testing and the FsCheck package because FSec uses the same approach to write generators. I chose this method because FsCheck is the most well-known package for writing properties in .NET.
Automating SQL injection vulnerability discovery with FSec
The FSec package has a
FSec.sqlInject generator that generates different types of injection strings, both valid and invalid, to make sure that the original query is altered in an unexpected way.Some examples of the input:
- ,
- ;
- —
- 1′ or 1=1–
- 999999 or 1=1 or 1=1
Automating URL bogus vulnerability discovery with FSec
Following example shows how an URL can be tampered. This can be used to verify if there’s any unexpected behavior with a URL.
Note: the
Http module comes from the FSharp.Data package.This snippet comes directly from the tests of this package. It starts from a base url
http://example.com with some required query parameters: category, style and size all with their own generator and builds a new URL with these required query parameters but also with a whole series of different query parameters.An example generation:
http://example.com?a0000001="c"&c0000003="<2"&category=""&d0000004=<null>&l0000012="n"&size="i"&style=<null>If you look closely, you can see that the original query parameters are there but also a lot of other things that can cause unexpected behavior.
Other Exposed Functionality
The FSec package exposes a whole range of other generators and also some functions to create some single-input values.
FSec.dicAttack: John the Ripper dictionary generator Generates weak passwords used for a dictionary attack.FSec.fileIllegalNames: Illegal file name generator to validate the file uploading mechanism. Generate file names with semicolons, reserved names, percent sign, ampersand, …FSec.xmlBomb: XML Bomb input generator: An XML bomb is a message composed and sent with the intent of overloading an XML parser (typically HTTP server). It is block of XML that is both well-formed and valid according to the rules of an XML schema. It is a type of XML Denial of Service (DoS) attack. (more info: https://en.wikipedia.org/wiki/Billion_laughs)FSec.zipBomb: Creates a zip file bomb having a depth and width representing the different levels the zip bomb should have.- …
More info on the package: https://stijnmoreels.github.io/FSec
Conclusion
Testing security vulnerabilities is just like any other testing approach, it’s an organic process. Some tests that suit your needs today will no longer server you in the future. For example tests that are used to discover vulnerabilities will eventually be removed in favor of tests that cover the intent.
Also, remember that testing security is an ongoing process and needs to be continuously verified. I’ve been working on the package FSec to abstract away some common known security vulnerabilities which are unfortunately still revalent.
Thank you very much for reading, and stay safe!
Subscribe to our RSS feed