Opportunities of Insecurity Refactoring for Training and Software Development

Abstract

Teaching software security is complex and should involve practical exercises. Practical exercises require software artifacts and projects that contain vulnerabilities. The vulnerabilities can be exploited to understand their impact on how different sanitization methods can be bypassed and how they can be mitigated. A frequent challenge is the creation of realistic projects that contain such vulnerabilities. The projects can be created manually with a lot of effort and can only be used once because exploiting the same vulnerabilities repeatedly will not provide a learning effect. The goal of this thesis is to provide a solution to automatically create such learning examples that are realistic and provide permutations that can be used repeatedly for teaching. As a solution to create learning examples automatically, we invented Insecurity Refactoring. Insecurity Refactoring is a change to the internal structure of a software to inject a vulnerability without changing the observable behavior in a normal use case scenario. Creating realistic vulnerabilities requires characterizing realistic vulnerabilities and identifying how they look like. To solve this challenge, we have reviewed the source code from 150 vulnerabilities that occurred in open-source projects in the categories SQL Injection, Cross Site Scripting and Buffer Overflow. From these vulnerabilities, we have categorized source code patterns of sources, sanitization, context, sinks, and fixes. Those patterns characterize realistic vulnerabilities and are used for Insecurity Refactoring. Additionally, the types of errors from the developers resulting in a vulnerability have been reviewed. Those point out the issues that should be taught to developers and mitigated in the development phase. Another challenge is creating learning examples that are difficult to detect by static code analysis tools. Those learning examples can also be used to teach developers what source code patterns should be avoided. The previously reviewed vulnerabilities have been scanned with a set of selected commercial and open-source static code analysis tools to identify patterns that produce false positive and false negative results. This insight allows mitigating such difficult patterns in the development phase to improve the effect of static code analysis. Additionally, these difficult patterns are used in the Insecurity Refactoring approach to create learning examples that cannot be solved by static code analysis tools. Our method of Insecurity Refactoring has been formalized by using a new defined Adversary Controlled Input Dataflow tree. The formalization allows detecting Possible Injection Paths. Those paths can be transformed into vulnerabilities. All the previously identified source code patterns are used to inject different permutations of vulnerabilities. We developed a tool to realize the formalized method. The tool was tested on open-source projects to check if the approach can inject vulnerabilities. If an open-source project is injectable it does not imply that it is less secure, instead it implies that static code analysis approaches can analyze them to find injection possibilities. The results have indicated that our approach can use 8.1% of the open-source projects found on GitHub to create learning examples. Projects transformed by our approach have been used as learning examples in two experiments with different groups. The results have shown that the Insecurity Refactoring method does not change the behavior of the program, except when the vulnerability is exploited. Accordingly, the definition of Insecurity Refactoring was confirmed. A survey of the attendees of the experiments has revealed that the transformed projects can be used as learning examples and that the examples are realistic. Another aspect of this thesis is to improve static code analysis tools. All the identified patterns have been combined to create two static code analysis benchmark data sets. The data sets have been scanned by commercial static code analysis tools. By calculating established static code analysis metrics, the data sets can be used to identify problems of the tools like high false alarm rate, low precision, low recall, etc. Additionally, we have provided a solution to identify patterns that the tools do not cover. The generation process has been discussed in an interview with experts from Software Assurance Metrics And Tool Evaluation (SAMATE) at the National Institute of Standards and Technology (NIST). They have approved that the generation process is solid. The two generated data sets are being hosted as an official Software Assurance Reference Dataset (SARD). This allows all developers of static code analysis tools to test their tools and improve it based on our research.