Security is an increasingly important part of building modern web applications, but developers often fall victim to the pressure of tight deadlines. In this course, we’ll get hands on both from the attacking and defending standpoint, and learn how to keep the baddies out.
1 — State of Web App Security
Before we jump in, let’s talk about the current state of Web Application security in comparison to the ops and infrastructure security world. We’ll also look at the typical categories of attacks, and what we can do as developers to make sure we’re not easy targets ourselves!Agenda
We’ll make sure everyone is set up for the workshop, and go over the day’s agenda.
State of Web App Security
We’ll look at the role web security plays in the world, dissect the methodology behind some recent high-profile attacks, and discuss some shocking statistics regarding the vulnerability of web applications worldwide.
Categories of Attacks
We’ll look at a modern web application system as a whole, and point out several places where an attacker can probe, interfere with, or otherwise compromise it.
Protecting Developer Secrets
Developers are part of the system and can be targeted easily. We’ll go through the exercise of putting a password in front of a SSH key, encrypting a text file, and effectively managing file permissions on a POSIX-compliant operating system.
EXERCISE: Developer Lockdown
Using our newfound knowledge of developer security best practices, it is time to lock down your own machine.
2 — Client-Side Vulnerabilities
The ability for users to inject content into web pages is the root cause of a broad class of vulnerabilities, which can affect the experience of other users, and leak potentially useful information out to an attacker. We’ll conduct some attacks in a controlled environment, and then learn how to defend against them in our own web applications.Agenda
Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) typically originates from failing to sufficiently sanitize user-generated content. We’ll look at how several types of seemingly benign user input can be used to inject some troublesome code into a web application.
ATTACK: Cross-Site Scripting
Find a way to use a cross-site scripting attack to inject a malicious script into the example web application, such that the user’s username and password are sent to a RequestBin when they attempt to login. The operation of the application should not be obviously affected.
DEFEND: Cross-Site Scripting
Use some content sanitization techniques to ensure that raw user-generated content isn’t used dangerously. This should result in your previous XSS attack being “disarmed”.
Cross-Site Request Forgery Attacks (CSRF)
Cross-Site Request Forgery Attacks (CSRF) attacks force users to take unwanted actions in an application to which they’re currently authenticated. We’ll look at how this attack works, and what we can do to mitigate against it.
Stage a CSRF attack against the online banking example app to get users who click a particular link to transfer funds from their account to another one.
Use a CSRF token to defend against request forgery attacks. Your attack in the previous exercise should no longer work.
Break for lunch
Clickjacking involves carefully placing a transparent frame in a way that tricks the user into clicking a legitimate button, ultimately resulting in users performing an unintentional action in another web application.
Stage a clickjacking attack using the example web application, by positioning a transparent frame of the “Blue” web application over the “Red” web application.
X-Frame-Options headers on the HTTP response for the “Blue” web application. This should disarm your previous Clickjacking attack.
3 — Server-Side Vulnerabilities
Attacks that cause a hosted application to operate in unexpected or unpredictable ways, can result in private data either leaking out through HTTP responses or logs.Agenda
SQL injection attacks take advantage of improper sanitization of user input, to execute unplanned SQL statements against a database. This can result in leaking of private information, or potentially, total destruction of the database.
ATTACK: SQL Injection
Identify and exploit a SQL injection vulnerability in the online banking example app.
DEFEND: SQL Injection
Alter the online banking app so that user input is sanitized. Now, your SQL injection attack should no longer cause private data to be disclosed.
Timing attacks, aim to get information out of a secure system by analyzing the time taken to perform certain operations – usually the time that’s related to the implementation of an encryption algorithm or other security measures.
Use a database of potential users, analyze login attempts to determine the users for which the password is actually evaluated, vs the users where the system doesn’t bother checking at all (i.e., non-user or disabled user).
Use a “dummy evaluation” to mitigate against a timing attack. Your solution to the previous exercise should have inconclusive results now.
4 — Network & Infrastructure Vulnerabilities
Even if you lock down your client and server side, it’s still our responsibility as developers to prevent users from getting into trouble when networks and certificates are tampered with.Agenda
Man-in-the-middle attacks, HTTPS and HSTS
There’s a good reason that the entire internet is moving toward HTTPS: it is exceedingly easy to observe and tamper with plain HTTP traffic. However, HTTPS is not enough! We’ll look at HTTP Strict Transport Security headers, and how we can save users from themselves.
Subresource Integrity (SRI)
What would happen if someone tampered with your CDN? Subresource Integrity (SRI) protects us from problems caused by tampered CDN, even when everything else fails. We’ll look at how an attack could be staged, and how SRI would save our users.
Wrap up and Recap
We’ll recap everything we’ve covered, and provide references for further reading and learning.