Presented at
Black Hat Asia 2017,
March 30, 2017, 10:15 a.m.
(60 minutes).
Security testing is difficult, no matter who is doing it or how it is performed. Both the security and development industries struggle to find reliable solutions to identify vulnerabilities in custom code, but sometimes make things harder than they should be.<br />
<br />
Over the past 20 years, the security industry has defined application security testing tools as separate from the traditional QA toolset, although both approaches are similar. Send test data (or payloads, exploits) to an application and inspect the response for appropriate or inappropriate behavior. The one-size-fits-all approach for security testing during the software development lifecycle (SDLC) does uncover security flaws, but leaves something to be desired, as it does not pinpoint the exact file/function where a vulnerability exists. Fuzzing application parameters is a great first step, but requires additional research and work to fix or exploit any identified flaws. Additionally, the traditional approach may not discover regressions in application code with the same speed and precision that unit-tests would.<br />
<br />
On the other hand, unit testing frameworks provided by programming languages and application frameworks often lack functionality necessary to perform security testing. This lack of coverage, test data, or even functionality reduces the overall effectiveness of a security unit test. In addition, identification of many security vulnerabilities, including cross-site scripting, requires fully functional application stacks with presentation layers. If the unit testing framework is missing any of these pieces, it is impossible to create a full security test suite. <br />
<br />
Due to both the aforementioned limitations as well as traditional security approaches to software security, custom and specific security testing is often overlooked and is not instituted within the typical software security testing tool suite. As developers and security professionals, we can do better. A hammer is not the only tool in our belt, and a scanner is not the only way to find a security vulnerability. Using DevOps practices such as Test Driven Development (TDD) and Continuous Integration (CI), it is possible to overcome both security and development weaknesses around unit testing and implement a custom security unit test suite for any application.<br />
<br />
This talk will first address the current limitations in security unit testing applications with existing tools and various frameworks. Next it will introduce a generic framework for creating security unit tests for any application. Then it will review common strategies for building application security-specific unit tests, including function identification, testing approaches, edge cases, regression testing, and payload generation. In addition, it will demonstrate these techniques in Java Spring and .Net MVC frameworks using intentionally-vulnerable applications. Finally, this talk will introduce sputr (https://github.com/sethlaw/sputr), an open-source repository of security unit testing payloads that can be used as a starting point for creating custom security unit tests.
Presenters:
-
Seth Law
- CSO, nVisium
Seth Law is an experienced Application Security Professional with over 15 years of experience in the computer security industry. During this time, Seth has worked within multiple disciplines in the security field, from software development to architecture to network protection, both as a manager and individual contributor. Seth has honed his application security skills using offensive and defensive techniques, including tool development and research. His understanding of the software development lifecycle allows him to speak as a developer and to equate security issues to development tasks. In his spare time, Seth revels in deep-level analysis of programming frameworks and inherent flaws.
Links:
Similar Presentations: