Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
In the last video, we explored how XSS works in theory. Now, let’s look at XSS in action and learn how to prevent it.
New Terms:
- Content Security Policy: a standard for adding which resources should be allowed to run (and which domains they can run on) via specific HTTP headers on a web app.
Further Reading:
OWASP XSS Prevention cheat sheet
Ngrok - A free service that let’s you access locally-running web servers via a unique, registered domain name in a matter of seconds.
SecurityHeaders.io
Content Security Policy overview: Developer Tools
Content Security Policy overview: OWASP Documentation
Content Security Policy Node.js Library (and other security headers)
Cross-Domain requests in JavaScript
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
In the last video,
we explored what XSS is and how it works.
0:00
Now, let's look at our application and
see XSS in action.
0:04
On the profile page, we see that we can
set several fields for our profile.
0:08
What if these fields don't sanitize
the data entered when saved inside
0:13
the application?
0:16
Working from that belief, let's try to
embed XSS inside the field of our own user
0:17
and then if the admin user ever loads all
the users in the dashboard, the embedded
0:21
XSS would be able to access any of
the admin's cookies or session tokens.
0:26
Now, we've entered a script tag with
an alert in the last name field.
0:48
And we hope this will be ran by other
users in the same way it was ran by
0:52
ourself.
0:55
Well, in the case of this application,
0:56
an admin user exists that oversees
the accounts of all of the other users.
0:58
As an attacker,
if we compromise this admin user,
1:02
we will have access to all kinds of
goodies, like the banking account numbers
1:05
of other users, their routing numbers,
and other financial information.
1:08
To see if our XSS worked, let's now log
in as the admin user which has access to
1:12
a special admin dashboard which
loads all users information.
1:16
My, as soon as we log in as the admin, the
script we inserted earlier is executed.
1:25
This is exactly what the attacker wants.
1:30
To remediate this vulnerability,
we need to do two things.
1:32
First, we want to make sure that our
HTML templates are auto escaped.
1:35
Meaning that any script tags and
1:40
other potentially unwanted characters
are sanitized and removed.
1:41
Second, we need to make sure that cookies
cannot be accessed via JavaScript
1:45
on the client side, which will
prevent any XSS that isn't remediated
1:48
from being able to steal
things like session tokens or
1:52
other sensitive data stored
in the client's cookies.
1:55
Even though the XSS here did not access
cookies, it would be an easy change for
1:58
an attacker to grab the cookies from
the browser document object model,
2:02
or DOM, and send them to their
own server with an HTTP request.
2:05
Now, in our application,
2:09
we can apply these fixes by adding
several configuration options.
2:11
In the main server file, server.js,
2:14
we can enable HTML encoding using the
engine that does templating called Swig.
2:17
Now, we will change autoescape from false
to true, which will enable autoescaping.
2:22
But what if we forget to
sanitize input everywhere or
2:28
the autoescaping doesn't apply
to a page we forget about?
2:31
To ensure any XSS vulnerabilities
present can't access sensitive data,
2:34
we can add middleware that sets all
cookies with the HTTP only flag,
2:38
which will prevent cookies from
being accessed by JavaScript.
2:42
We'll also do this in the server file,
server.js.
2:45
Keep in mind, if other contexts existed
that accepted user data like CSS,
3:03
XML or other HTML attributes
like the attrib attribute,
3:07
we would need to sanitize or
autoescape for those contexts as well.
3:11
To summarize, preventing XSS
attacks means doing a few things.
3:16
The first line of defense is always
sanitizing and validating user input.
3:20
Libraries exist to do this in Nodejs and
3:24
JavaScript, which will be
linked in the teacher's notes.
3:26
However, beyond sanitization, encoding
should be applied to the output for
3:29
the context it originates from.
3:33
That means if you're putting
untrusted data into an HTML tag or
3:35
attribute, you should encode characters
like the less than symbol and
3:39
greater than symbol, which will prevent
JavaScript from running in that context.
3:43
If you're inserting user input into URLs
and href attributes or when inserting
3:47
entrusted data into CSS, you should encode
and escape all ASCII special characters.
3:52
The OWASP XSS prevention guide
linked in the teacher's notes
3:58
goes into these types of
encoding in more detail.
4:02
Next you should set the HTTPOnly
flag on cookies in your application,
4:04
which ensures that cookies can't be
accessed by JavaScript on the client side,
4:09
and thus can't be stolen by attackers
whose XSS does get through.
4:13
You should also apply encoding both
on the client and the server side.
4:18
This ensures that your app can
mitigate DOM-based XSS as well.
4:22
The non-trusted data never
leaves the client's browser.
4:26
The last and
4:29
more recent XSS prevention mechanism is
known as content security policy, or CSP.
4:30
CSP is a browser side mechanism which
allows the developer to create a whitelist
4:34
for client-side resources used by the web
application including JavaScript, CSS,
4:40
images and more.
4:44
CSP is applied via special HTTP
header that instructs the browser to
4:47
only execute or render resources
from the specified sources.
4:52
For example,
this CSP header allows content
4:56
only from the main Treehouse domain and
all its sub domains.
4:59
CSP has libraries with implementations
in nearly every modern language.
5:04
We will link the relevant libraries for
Node.js in the teacher's notes.
5:08
Another great resource you can
check out is SecurityHeaders.io.
5:12
It's a site that lets you put
in your web app's domain name,
5:14
and it will check to ensure you're
covering your bases in XSS.
5:17
This is an invaluable resource for
5:21
ensuring you hit all the low-hanging
fruit when protecting your apps.
5:23
In the next video, we will explore
cross-site request poetry or
5:27
CSRF which allows an attacker to perform
actions on behalf of victim users.
5:30
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up