Course Overview: Web Security Essentials
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.
Mike Sharav: [0:00] Security is important and is often overlooked and forgotten. Part of the reason for this is that security seems hard to get right. One of the best ways to protect your application from attack is to first understand how attacks are carried out and then learn how to mitigate them. Application security doesn't need to be overwhelming.
[0:18] In this course, we'll cover session hijacking and how to prevent it, secure cookie configuration and making them hard to steal. Using chralesproxy to simulate a man-in-the-middle attack, using HTTPS and HSTS to mitigate man-in-the-middle attacks. Using CSRF tokens in same [inaudible] keys to mitigate CSRF attacks. Using the CSP to mitigate XSS attacks. You'll learn security rules of thumb such as defense in-depth and principle of list power.
[0:48] We'll learn all this by finding and exploiting vulnerabilities and then patching them on our target website in a game of security cat and mouse. To get our target website running and to perform our attacks, we'll need a bit of a setup. Note that these instructions are for macOS or Linux. You could find instructions for Windows in the remit section of the source code for this course.
[1:08] First, download charlesproxy from charlesproxy.com/download. When you open it, after a splash screen, it should look like this, the list of URLs your computer is making a request to. You'll also need some command line utilities.
[1:25] First you'll need Git, which you can check to see if you have by running git--version. Next, you'll need node JS, which you can check by running node--version. You'll need a version higher than version 8.9.3. If you don't have node yet, you could download it from nodejs.org. Node comes with npm, which you can check by running npm--version.
[1:49] Finally, you need a cURL which also you can check with curl--version. If you don't have it, you can get it at curl.haxx.se. Next, you'll need to make sure that you have pseudo privileges or that you can run a command line as an administrator if you're using Windows.
[2:06] We'll modify our host file which is located at etsy/host. We'll look for the localhost entry, which is that IP address 127...1. To this, we'll add evil.com and hit save. Because this is a protected file, we'll have to see it again as pseudo.
[2:29] I'll enter my password. This makes it so that when I visit evil.com, which will be our fake attacker website, it will resolve to my local computer.
[2:40] Next, run pseudo npm install from the root of the repository. This will prompt you for your password. For this course, you'll only ever have to npm install this one time. All dependencies for all the lessons are installed upfront.
[2:58] Now go to the first lesson by cd-ing into exercises/01, and run pseudo npm start. You should get a messages saying to visit http://localhost.charlesproxy.com. If you open that URL, you should see a username and password prompt.
[3:21] Next, we'll want to start our evil.com attacker website. For this, we'll run pseudo npm run start:evil.com. This should start a server on https://evil.com:666/index.html. If you see "Thanks for visiting," it worked.
[3:42] Our application doesn't have much to it. It has a log in form. Once logged in, it has a message form that either allows you to send a specific message or send a hello message via one button. It also displays our username and our Social Security number, the perfect type of information suitable for a hacker to steal.
[4:03] If you visit login.js, you'll notice that we have a database of users here. This is the username and password for our site. You'll be logging in with the username Mike Sharav, and a password of 1. Let's get started.
1:08 First, download charlesproxy. Link is broken. https://www.charlesproxy.com/download/
If you are running a VPN, you'll need to start Charles Proxy before starting your VPN. https://www.charlesproxy.com/documentation/faqs/vpn-not-working-with-charles/
This took me some time to figure out so I thought I would give a heads up.
1:08 First, download charlesproxy. Link is broken. https://www.charlesproxy.com/download/
Thanks for this! I went ahead and got all of these links fixed for you guys.
The "code /etc/hosts" command is supposed to open the file in VS Code. If you have VS Code installed but the terminal does not recognize the code command, follow the directions for Launching from the command line here: https://code.visualstudio.com/docs/setup/mac
This is a security course and one of the first things you instruct people to do is sudo npm install which is dangerous, a bad idea, and really shouldn't be required. I'd suggest re-recording the first episode and removing that. Here's the first blog post that came up when I googled sudo npm install: https://medium.com/@ExplosionPills/dont-use-sudo-with-npm-still-66e609f5f92
Hi Aaron,
I agree. In general, you should never use sudo for a command that you don't have to. In the generic case of npm install, indeed if a malicious script was present it would execute with escalated privs... a terrible idea.
However, in this specific case of npm install, you are installing the dependencies that are in the package-lock.json file, which are locked to known safe dependencies. So for the purpose of this course, running this specific sudo npm install is perfectly safe.
The other reasons for not sudo npm installing are not security related, and again, as generic advice make sense.
It just so happens though that those reasons don't apply to the specific sudo npm install we're doing.
Hi Mike,
Though you may have personally audited all of the dependencies here: https://github.com/mikesherov/web-security-essentials/blob/master/package-lock.json your viewers will likely not have. Asking people to run sudo npm install without a giant warning and encouraging them to first audit those dependencies is what I have a problem with, especially in a course about security.
The bigger question is, why require sudo npm install in the first place?
Hi Aaron,
The package https-localhost, which we use to get a local https server running which installs a root cert on your computer to avoid the "self signed certificate" warnings you'd get with local https otherwise, can require some of its files to be owned by root when it automates this setup. Several of my students who attended workshops, and myself included had this issue. The package itself notes this in its install instructions (look for it says "this may require sudo") underneath the npm install step.
https://github.com/daquinoaldo/https-localhost/
The point of the lesson is to set up the course as quickly as possible, and asking my students to audit the dependencies in the lock file when I know they are safe provides a distraction.
I appreciate your feedback here and will incorporate it into future lessons but I feel confident this is the right choice for this lesson, which has a goal to get you up and running.
Thanks again for taking the time to discuss this issue and call it out, it's valuable!
On Windows, this did not work, but if you use cross-env-shell inside packages.json on the start and start:evil command, it works. Tips here: https://stackoverflow.com/questions/58924328/generic-node-js-init-cwd-for-windows-and-nix
Just launched the sudo npm run start:evil.com. Server seems to be working, but nothing displays on evil.com:666/index.html in the browser
Just launched the
sudo npm run start:evil.com. Server seems to be working, but nothing displays onevil.com:666/index.htmlin the browser
Nevermind the whole address is not evil.com:666/index.html but https://evil.com:666/index/html.
Silly me.
Hi Mike，how nodejs listen 80 port?
For me, $INIT_CWD wasn't getting set, so running the sudo npm start command from within the first exercise directory wasn't working for me.
I then tried what the README suggested: nodemon ./site/index.js (again from within ./exercises/01, but I didn't want to have a globally-installed version of nodemon so instead I used: ../../node_modules/.bin/nodemon ./site/index.js
I haven't used npm in a while, so I'm probably missing an easier way of access the executable of a local package, but also worth noting that both from the root directory (or for that matter, from the specific exercise directory, but probably not worth cd'ing into it in this case) you use yarn to easily access the local nodemon executable and run the exercise:
yarn nodemon ./exercises/01/site/index.js
Just posting this in case it helps anyone :)
For the code on GitHub, it's the tags that correspond to the lesson title and not the branch name.