As developers, we have a responsibility to protect the data our users trust us with. No one wants to wake up to the news that their site was hacked and all of the user accounts stolen.

Security is important, yet it is often overlooked and forgotten.

Part of the reason for this is that security seems hard to get right. This results in developers crossing their fingers and hoping for the best.

In this course, you'll learn how to protect your application by learning how to attack it.

Start your journey into web security today!

Check out these [**community notes for this course on Github**](https://github.com/wjohnson85/eggheadio-web-security-essentails).

In this course, we'll learn how to exploit and then mitigate several common Web Security Vulnerabilities: Man in the Middle (MITM), Cross Site Request Forgery (CSRF), and Cross Site Scripting (XSS).

The goal of this course is to introduce you to these attacks from the point of view of an attacker, and then as the defender of a sample application, and to gain first hand experience with how these attacks works. You'll also learn several security "rules of thumb" along the way and discover modern defenses against these attacks that drastically reduce their likelihood of succeeding!

By the end of this course, you’ll know how to recognize these vulnerabilities in your own application and have strategies to mitigate and defend against all of them. You'll feel more confident in your ability to write secure code, and my hope is that you'll be inspired to continue your security journey and help make the internet a safer place for all of us.

Course Overview: Web Security Essentials

In this lesson, we'll learn how to use Charles Proxy to “sniff” the web traffic flowing an example website using an attack known as a Man in the Middle attack, or MITM. Because our example website is using http and not https, you'll “discover” a vulnerable piece of user data called a session id being transmitted in cleartext across every request. This info will become the central piece of data that we'll learn how to protect throughout this course.

Simulate Man in the Middle Attacks and Inspect Network Traffic with Charles Proxy

In this lesson, we'll learn how to add https (and remove http) support to the localhost version of our express application. By adding https support, we'll be able to prevent a MITM (in this case Charles Proxy) from reading our session id, mitigating the attack known as "session hijacking".

Add https to a Localhost Express App to Prevent MITM Attacks

In the previous lesson, we disabled http in favor of https. In this lesson, we'll learn that the default protocol for web browser is http, and we therefore need to provide an http endpoint that redirects the browser to https. We'll do that by setting up a small express application whose sole responsibility is to redirect http urls to https. In doing so, we'll accidentally reintroduce the transmission of our session id over http, which we'll need to fix in our next lesson.

Redirect All HTTP Traffic to HTTPS in Express to Ensure All Responses are Secure

In this lesson, we'll will learn how to set the `secure` flag on our session id cookie to ensure it is only transmitted over https connections. This will effectively mitigate the Session Hijacking vulnerability we introduced in the previous lesson.

Set the Secure Cookie Flag to Ensure Cookies are Only Sent Over Secure Connections

In this lesson, we'll learn how to add HSTS headers to an express application so that all requests after the first request made to the application are https. We'll also learn about the HSTS preload list which will ensure that even the first request is secure. Even though we secured our session id cookie in the previous lesson, ensuring all requests go over https ensure that even if we add another cookie and forget to set it to Secure, we'll still not be transmitting it in cleartext over an http connection.

Add HSTS Headers to Express Apps to Ensure All Requests are https Requests

In this lesson, we'll learn what a Cross Site Request Forgery (CRSF) vulnerability is by learning how to exploit a CSRF vulnerable site by making malicious requests on behalf of a logged in user. We'll construct a malicious payload that automatically gets POSTed to the vulnerable site simply by visiting the attacker website while being logged into the target website.

Create a Proof of Concept Exploit of a CSRF Vulnerable Website

In this lesson, we'll learn what the SameSite cookie flag is, what it’s various settings are, and how it can be used to prevent most forms of CSRF vulnerabilities. We'll then demonstrate how it protects against the exploit we crafted in the previous lesson.

Mitigate CSRF Attacks by Setting the SameSite Cookie Flag in Express

In this lesson, we'll learn what CSRF tokens are, and how they are used to defeat Cross Site Request Forgery vulnerabilities. Even though we've defeated CSRF through the use of SameSite cookies, adding CSRF tokens are an important "defense in depth" strategy to ensure that browsers that don't support SameSite cookies can still be protected against CSRF.

Add CSRF Token Middleware to an Express Server to Mitigate CSRF

In this lesson, we'll learn how to exploit an XSS vulnerability to read the contents of a cookie from our vulnerable website.  We'll also make an endpoint on our attacker website to receive and log the cookie we've stolen. This payload will be used and modified in the following lessons to validate vulnerabilities and to verify their mitigation.

Make an XSS Payload to Read a Cookie from a Vulnerable Website 

In this lesson, we'll learn how to set the httpOnly flag on our session id cookie to ensure it is inaccessible from javascript, thereby defeating theft of the session id from the XSS attack we crafted in the previous lesson. However, we'll still leave ourselves open to other dangers from XSS, which we'll exploit in our next lesson!

Set the httpOnly Cookie Flag in Express to Ensure Cookies are Inaccessible from JavaScript

In this lesson, we'll learn how to exploit an XSS vulnerability to read the contents of the page body from a vulnerable site, capturing whatever sensitive information is on the page, and sending it back to our attacker website for further exploit. This will effectively show that XSS must be completely stopped, rather than stopping a specific type of exploit such as cookie theft via XSS like in our previous lesson.

Make an XSS Payload to Read document.body from a Vulnerable Website

In this lesson, we'll learn what CSP is and how it can be used to prevent inline scripts from being executed on our vulnerable website. First, we'll deploy CSP in "report only" mode, which will send violations to the endpoint you specify without blocking execution. Then, we'll run CSP in regular mode, which we'll use to completely block inline scripts from executing.

Prevent Inline Script Execution by Implementing Script-Src CSP Headers in Express

In this lesson, you will learn how to exploit an XSS vulnerability to read the contents of the page body from a vulnerable site, this time by loading up a script from their attacking domain instead of inlining the javascript, using an attack known as Remote Script Tag Injection. This attack will succeed because in the previous lesson, we only blocked inline scripts from executing. We'll solve this problem in our next lesson!

Read Document Content from a Vulnerable Website via Script Tag Injection in an XSS Payload

In this lesson, we'll learn how to set the script-src CSP to use nonces. Using nonces will disallow both inline scripts and remote scripts from executing unless the script tag has a nonce attribute that matches the nonce provided by the CSP header. This will mitigate the vulnerability we discovered in the previous lesson and will effectively block all javascript from running except the scripts you explicitly added, and is an effective defense against javascript powered XSS!

Add a Nonce Based script-src Header in Express to Only Allow Scripts that Match the Nonce

In this lesson, we'll learn how to exploit an XSS vulnerability to prompt victims for their usernames and passwords on a vulnerable site by loading up a IFRAME from the attacker's website. This will demonstrate that even though we've already mitigated JS based XSS attacks, there are other ways to exploit XSS, and we'll need a more robust CSP header to completely mitigate XSS, which we'll discover in our next lesson!

Prompt Users for Credentials from a Vulnerable Website via iframe Injection

In this lesson, we'll learn how to disable all external content srcs other than the specific types of external resources we need. For the types of external resources we need, we'll limit those resources to only nonce-matching resources. This will effectively mitigate all forms of XSS, using the principle of least power to only enable needed capabilities, and drastically reducing the surface area of possible attacks on our website.

Web Security Essentials: MITM, CSRF, and XSS

Instructor

What you'll learn

Course Content