As web applications get more complicated and more integrated into our daily lives, securing them against known cyber attacks is of great importance. Performing security tests is the primary way to discover the current risks and act accordingly. In order to perform these test in a systematic way, testers create and use numerous vulnerability lists and testing guidelines. Often, dedicated security institutions like Escal Institute of Advanced Technologies (SANS), MITRE, Certified Secure, and the Open Web Application Security Project (OWASP) create these guidelines. These lists are not meant to be exhaustive, but as the introduction in the Common Weakness Enumeration (CWE) of MITRE and SANS by Martin et al. (2011) puts it: they "(..) evaluated each weakness based on prevalence, importance, and the likelihood of exploit". This seems like a reasonable way of thinking, but as we have shown in this research, it can also lead to oversight of essential, but stealthy security issues.

In this research, we will focus on one such stealthy issue in web apps called a race condition. Race conditions are known for a very long time as research by Abbott et al. (1976) shows. Still, they are a type of security vulnerability that is often not included in these lists as it is challenging to test for and also is not often exploited. Based on the lack of research in this field, we argue that especially in the web-environment, it has resulted in an underestimation of the risks involved. The races continue to show up in web apps and when exploited, could have a significant impact as a recent security blog by Jadon (2018) shows. This impact ranges from circumventing any limited-usage functionality like coupon redemption to enabling other types of security vulnerabilities like privilege escalation or a Denial of Service (DoS).

That is why, in this research, we developed the first systematic method to test for race conditions in web apps from a black-box perspective. We also built a tool to support the exploitation and evaluated both in comparison with related tools.

1. Methodology - we have devised the first method for systematically testing for race conditions in web apps from a black-box perspective. Most importantly, this method contains a list of common race condition vulnerabilities in web apps and a detailed strategy of how to test for these items.

2. Toolset - Next to this, we have developed the toolset called CompuRacer to support the tester in the execution of this systematic test. It supports the gathering of HTTP requests of interest, the parallel sending of these requests and guided evaluation of responses.

3. Evaluation - toolset - Subsequently, we have evaluated both the toolset and method. In order to do this, we compared the toolset to three related toolsets on a functional-, usability- and performance-level. For the performance evaluation, we used the tools in a real-life setup on a self-developed web app that is vulnerable to race conditions. In this evaluation, we tested the raw speed of sending parallel requests and the ability to exploit race conditions using the appropriate statistical tests. Regarding all of these metrics, the toolset is shown to be equal or better than all other tools.

4. Evaluation - method - Finally, the method and toolset are evaluated together on seven web apps ranging from e-commerce platforms to blogs and wikis. We were able to find much minor race condition related issues in these platforms, but more importantly, for two e-commerce platforms, a severe vulnerability has been found and reported which has a significant financial impact.

Based on this, we conclude that we have successfully created a method and toolset that are sufficient for security testing. We are also aware that much more research is required to expand upon these findings. Still, we hereby achieved the first step towards systematic testing for race conditions in web apps, and by that, we hope that this will have a positive effect on software quality in the future.