1.1 About This Book
In 2009, hackers obtained user credentials of over 30 million users of mobile game publisher RockYou. They exploited a SQL injection vulnerability to obtain the site’s user table. To make matters worse, passwords were stored unencrypted, allowing the hackers to obtain their passwords without further need to crack them.1
In 2010, a developer released a Firefox extension called Firesheep that enabled eavesdroppers to obtain session IDs of Facebook and other sites logged in through the same Wi-Fi network. This enabled the eavesdropper to log in as that user without needing to enter a password.2
In 2017, hackers obtained the records of over 130 million individuals from credit bureau Equifax. The vulnerability was in a web framework Equifax was using, Apache Struts. The vulnerability has already been identified and fixed by Apache, but at the time of the hack, Equifax had not updated to the patched version.3
These three examples demonstrate that even large, often reputable organizations can get hacked. In each instance, the breach was preventable. In this book, we will look at the vulnerabilities that lead to these compromises, along with many others, and, of course, how to fix them.
Web application security is an ongoing war between hackers and developers. If we, as developers, simply learn techniques to make applications more secure, without understanding the attacks fully, hackers will find other vulnerabilities to exploit. Therefore, we must understand how hackers discover and exploit vulnerabilities. We must also understand why defenses work and what attacks they do and do not prevent.
Most importantly, we must use several techniques together and choose a set of defenses that fit with the requirements of our application while at the same time making our applications secure enough to prevent or minimize attack.
In this book, we will look at the vulnerabilities hackers exploit to compromise our systems and how they discover them. We will simulate the attacks through hands-on examples. In each case, we will look at techniques to close the vulnerability or reduce its impact. Again, through hands-on examples, we will see why these approaches prevent attacks as well as the vulnerabilities they do not address. By understanding the details of these techniques, you can use them together to make your applications more secure while still giving your users a sufficient quality of service.
To make practicing exploiting and fixing vulnerabilities easier, a GitHub repository with code for two complete virtual machines accompanies this book. The repository is at
https://github.com/mbakereth/django-coffeeshop
and we will introduce it more fully in the next chapter.
1.2 Who This Book Is For
This book is aimed primarily at software engineers who develop, or want to develop, web applications and APIs. It is also written for penetration testers who want to understand more about how web applications are written and how they are attacked. It will also suit managers and security policymakers who want to know what threats web applications face and what measures can prevent attacks.
This book is very hands-on. We believe you only truly understand a concept when you put it into practice. Throughout the book, we will use a sample web application called Coffeeshop to practice exploits and fixes on. It is written in Python with the Django web application framework. This application runs in a pair of virtual machines (VMs) on Ubuntu Linux through the Apache web server. To follow the exercises, you will install the VMs on your PC, Mac, or Linux workstation.
You will need some familiarity with Python to fully understand the exercises. However, the security concepts and exploits in this book are not language specific, so, exercises aside, most of the book is relevant for other languages too. A basic understanding of the Django web framework and Linux operation system is also helpful. However, if you do not have this, there is a link to Django documentation and a crash course in Linux in the next chapter.
1.3 Types of Attack
When we talk about web applications, we mean applications whose UI is in a web browser that communicates with a server over HTTP or HTTPS. We also include Websockets and HTTP streaming in this definition, when the connection is made from a page delivered over HTTP or HTTPS; however, we do not explicitly deal with these topics in this book. It also refers to APIs that communicate over HTTP and HTTPS, even if they do not have a UI.
There are two broad categories for web application attacks: server side and client side.
Server-Side Attacks
Exploiting vulnerabilities in your code, such as SQL injection to perform malicious operations on your database
Opening backdoors to obtain shell access on your server
Exploiting permission misconfiguration to access files or URLs that should be unavailable
SQL injection vulnerabilities occur when user input, for example, from form input fields, is concatenated with SQL query code. If the concatenation is not done safely, attackers can execute their own code on the database. We look at this in Chapter 7.
Backdoors enable hackers to obtain shell access on your servers. Hackers are able to open them when there are certain vulnerabilities in your code or third-party servers, libraries, and frameworks. An example of a vulnerability is code that executes a shell command, concatenating text entered by the user in a form field with commands in the back-end code. This may enable the hacker to run a shell command to open a port they can connect to. This is also discussed in Chapter 7.
Permission misconfiguration can include files having the wrong operating system permission (writable by the web server user, for example), or a misconfigured application permission system that allows unauthorized users access to URLs that should be password protected, or for admins only. We look at these vulnerabilities in Chapters 5 and 10.
Client-Side Attacks
Cross-Site Request Forgery, exploiting the fact that a user is already logged into a service
Clickjacking, getting a user to unknowingly follow a disguised link
Cross-site scripting, where an attacker gets JavaScript code executed in the victim’s browser to access their account or cookies
Cross-Site Request Forgery is an attack where a victim is enticed to follow a link on a site that they are logged into, but that performs an action in the attacker’s favor. An example is a link to do a transfer from the victim’s bank account to the attacker. If the victim is logged into the bank and the site is not properly defended against this attack, then the transfer may get executed, possibly without the victim being aware.
Clickjacking attacks trick users into clicking on a malicious link. The link may be disguised, for example, by superimposing it over a legitimate link and making it invisible.
Cross-site scripting attacks aim to get JavaScript code executed by a victim through their browser. This may be by uploading malicious code to an application or by sending a user a link with malicious JavaScript in an email. They often target session IDs users have stored in their browser.
We look at these attacks in Chapter 8.
Defenses against client-side attacks aim to protect users when they unknowingly follow a malicious link. These defenses do necessarily not protect your services from an attacker accessing them directly. For this, we use server-side defenses.
1.4 Defense in Depth
Defense in Depth is the practice of layering defenses. For example, our code should be written in such a way as to prevent unauthorized users from accessing our password file. We will ensure there are no SQL injection vulnerabilities and that unauthorized users cannot log into the server. However, in case these defenses fail, we also make sure passwords are hashed so that if the table is compromised, the hacker still does not obtain the passwords, at least not without a significant amount of work to crack them. We mentioned RockYou at the start of this chapter. If users’ passwords in their table had been hashed and they had better password policies (e.g., requiring digits and punctuation characters), hackers would not have obtained access to users’ accounts, even with the SQL injection vulnerability. We look at password hashing and password policies in Chapter 9.
Physical
Technical
Administrative
Physical defenses include locks on doors, security cameras, etc. Technical defenses are the ones we code into our systems, such as password authentication, checking form input, and cookie management. These are the main focus of this book. Administrative defenses are human procedures such as training staff, four-eyes principles, and monitoring logs. We usually use all of these categories to protect our applications.
1.5 Conventions Used in This Book
Throughout this book, we will use monospaced font for text that is printed by the computer, or text that should be inputted into the computer. When it is not obvious which is which, we put input text in bold.
Menu items and button text are displayed in italics, with capitalization that matches what is on the screen.
Sometimes, a command in Bash or Python does not fit on a single line in this book. When this happens, we end the line with a backslash. In these cases, you can literally type the backslash and enter the command over two lines, or you can omit the backslash and enter the text without the line break.
1.6 How This Book Is Organized
In the next chapter, we will introduce the hands-on environment. We will install two VMs running web applications that we can practice hacking and then securing against attack. We will use these VMs to practice techniques described throughout this book.
In Chapter 3, we look at some techniques for modelling threats. We will rarely be able to make a website 100% safe against all concentrated attacks, but often we do not have to. In this chapter, we learn how to identify risks and decide which to secure against and which to accept or just mitigate.
In Chapter 4, we look at the fundamental building block of web applications: HTTP. We also look at different types of encryption used in web applications and how they secure against attack. It is important to understand how the HTTP protocol works so that we can see where vulnerabilities can lie.
The next chapter, Chapter 5, is about configuring our underlying services and making them secure: web servers, database servers, securing operating system ports, and so on. We also look at some common attacks on servers and how to prevent them.
Chapter 6 covers a fundamental feature at the heart of all web applications: URL endpoints. We also look at REST APIs, what HTTP method should be used for what purpose and why (GET, POST, etc.), and making deserialization attacks and unit testing permissions.
In Chapter 7, we look at two of the most common sources of vulnerabilities: user input (through forms, URL query strings, etc.) and cookies. As we will see, cookies are often used for authentication in place of usernames and passwords, so they form a critical part of our security landscape. We look at common attacks such as SQL injection and cross-site scripting, as well as how to protect our code against them.
Chapter 8 explores how we make requests to other sites securely. We look at techniques to protect our application against malicious resources on other sites. We also look at Cross-Site Request Forgery and how to protect our users from it.
In Chapter 9, we take a deep-dive into password management: how to protect them against cracking attacks, what password policies we should implement, and how to code password reset pages.
Armed with a knowledge of how to store passwords, we look at authentication and authorization in Chapters 10 and 11. In Chapter 10, we cover common authentication patterns such as username/password, one-time passwords, and multifactor authentication. We look at some common authorization models such as implementing role-based authentication and creating API keys. The next chapter focusses on OAuth2, a standardized framework for authorization.
Inevitably, there will be attempted attacks on our servers. We can only really prevent attacks if we monitor our server and application. In Chapter 12, we look at logging and monitoring. As an exercise, we set up logging for our Coffeeshop application using a popular stack: ELK, or the Elastic Stack.
Chapter 13 steps back from making our code secure and looks at the wider process of developing and releasing software. We look at supply chain security: secure every step in that process. We also look at using third-party components safely and take a brief look at the sorts of attacks that hackers can launch against our staff, rather than against the application.
Finally, we go through some additional useful resources in Chapter 14 and summarize what we’ve learned. But to start with, let’s install some software and build our test application.