[PDF] todd lammle ccna pdf 2019
[PDF] tokyo itinerary
[PDF] tokyo itinerary pdf
[PDF] tokyo pdf lonely planet
[PDF] tokyo pdf map
[PDF] tokyo pdf travel guide
[PDF] tokyo summer itinerary
[PDF] toms port guides caribbean
[PDF] tool rental center
[PDF] tool rental gresham
[PDF] tools for climate change vulnerability assessments for watersheds
[PDF] top 1
[PDF] top 10 countries affected by climate change 2019
[PDF] top 10 restaurants in paris
[PDF] top 100 furniture stores 2019
1
Faculty of Electrical Engineering,
Mathematics & Computer ScienceTowards
Systematic Black-Box Testing
for Exploitable Race Conditions in Web AppsRob J. van Emous r.j.vanemous@student.utwente.nl
Master Thesis
June 2019Supervisors:
prof. dr. M. Huisman dr. ing. E. Tews (Computest) M.Sc. D. Keuper
Formal Methods and Tools Group
Faculty of Electrical Engineering,
Mathematics and Computer Science
University of Twente
P.O. Box 217
7500 AE Enschede
The Netherlands
ABSTRACT
As web applications get more complicated and more integrated into our daily lives, securing them against known cyber attacks is of great importance. Performing se- curity 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 numer- ous 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, iii IV 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 gath- ering 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 evalu- ation, 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 ap- propriate 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.
PREFACE
In my heart, I am both a meticulous software developer and a curious seeker of truth. In academics, but also in other aspects of life, I experience that this goes hand in hand perfectly. I remember that often when a professor teaching calculus would make a remark about the computational complexity of a function, I would instantly be prompted to write some code to verify his claims. They were always right. Likewise, when creating software for other reasons like the automation of processes and exploration of ideas, it feels like both an amazing privilege and a significant responsibility. That is why I pursue to develop and encourage well written and secure software. This often requires countless hours of designing, building, testing, and building some more, but the end result is worth it. So it has been with my thesis. "Failures, repeated failures, are finger posts on the road to achievement. One fails forward toward success."as C.S. Lewis would cleverly put it. The research was challenging but practical enough to fulfil my creative desire while hopefully still being a truthful enrichment to the academic world. v VI
ACKNOWLEDGEMENTS
There would be no way I could have achieved this result on my own. Firstly, I would like to thank my parents, brother and girlfriend for their loving support. Secondly, my committee members, each of whom has been patient with me in times of doubt and provided me with the necessary guidance throughout the process. Finally, as a follower of Christ, I would like to thank God for the love and support I believe He provides for me in life, but especially during this intense final period of my studies. "For I can do everything through Christ, who gives me strength."
Philippians 4:13 - The Holy Bible (NLT)
vii VIII
Contents
List of Figures xiv
List of Tables xv
List of Listings xv
List of Acronyms xvii
1 Introduction 1
1.1 Problem description & motivation . . . . . . . . . . . . . . . . . . . . .
1
1.1.1 Importance of secure web apps . . . . . . . . . . . . . . . . . .
1
1.1.2 Danger of race conditions explained . . . . . . . . . . . . . . .
2
1.1.3 Difficulties in testing for race conditions . . . . . . . . . . . . .
6
1.1.4 Overview of current web app testing methods . . . . . . . . . .
7
1.1.5 Classical race conditions tests for single-tier applications . . .
8
1.2 Research questions and methodology . . . . . . . . . . . . . . . . . .
10
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.4 Commissioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.5 Structure of the work . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2 Background 15
2.1 Race conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2 Web applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.2.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.2.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.2.3 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3 Software testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.1 Essential software testing dimensions . . . . . . . . . . . . . .
23
2.3.2 Security testing . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.3.3 Location of race condition testing . . . . . . . . . . . . . . . . .
28
3 State of the art 29
ix XCONTENTS3.1 Client-side race conditions . . . . . . . . . . . . . . . . . . . . . . . . .29
3.2 Detection of server-side race conditions . . . . . . . . . . . . . . . . .
33
3.2.1 Published work . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.2 Articles and blogs . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.3 Open source tools . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2.4 Testing the open source tools . . . . . . . . . . . . . . . . . . .
40
4 Creating a systematic method for web app testing 43
4.1 Definition of a race condition . . . . . . . . . . . . . . . . . . . . . . .
43
4.2 Development of methodology . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.1 Map website functionality . . . . . . . . . . . . . . . . . . . . .
47
4.2.2 Functionality to race conditions . . . . . . . . . . . . . . . . . .
47
4.2.3 Select HTTP requests . . . . . . . . . . . . . . . . . . . . . . .
55
4.2.4 Send HTTP requests . . . . . . . . . . . . . . . . . . . . . . . .
57
4.2.5 Evaluate attack . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5 Developing the CompuRacer toolset 63
5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.1.1 Gathering of HTTP requests . . . . . . . . . . . . . . . . . . .
64
5.1.2 Composing and sending of HTTP requests . . . . . . . . . . .
64
5.1.3 Handling of HTTP responses . . . . . . . . . . . . . . . . . . .
66
5.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.2.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
5.2.2 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.3.1 Core - Main class . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.3.2 Core - REST server . . . . . . . . . . . . . . . . . . . . . . . .
74
5.3.3 Core - Command Line Interface (CLI) . . . . . . . . . . . . . .
75
5.3.4 Core - Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.3.5 Core - Async Batch sender . . . . . . . . . . . . . . . . . . . .
78
5.3.6 Burp extension . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.3.7 Browser extensions . . . . . . . . . . . . . . . . . . . . . . . .
82
5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
6 Evaluation of toolset and testing methodology 83
6.1 Evaluation - Toolset functionality & usability . . . . . . . . . . . . . . .
84
6.1.1 Definition of metrics and scores . . . . . . . . . . . . . . . . . .
84
6.1.2 Rating the tools according to metrics . . . . . . . . . . . . . . .
quotesdbs_dbs17.pdfusesText_23
[PDF] Towards Systematic Black-Box Testing for Exploitable Race