WEBVTT

00:00:01.159 --> 00:00:03.730
If a cross-site scripting attack is

00:00:03.730 --> 00:00:06.159
successful, it means somehow JavaScript

00:00:06.159 --> 00:00:10.659
ended up in a web page that doesn't belong

00:00:10.659 --> 00:00:13.492
there. It's easier than you think. An

00:00:13.492 --> 00:00:15.159
attacker could inject JavaScript somewhere

00:00:15.159 --> 00:00:19.242
in your application. This can be done in

00:00:19.242 --> 00:00:22.492
many ways using an HTML input field, a

00:00:22.492 --> 00:00:25.659
cookie, and a query string, and from a

00:00:25.659 --> 00:00:28.977
database, for example. It works as long as

00:00:28.977 --> 00:00:31.659
the input is mirrored back somehow. Let me

00:00:31.659 --> 00:00:35.159
show you. On the demo site, on the page

00:00:35.159 --> 00:00:36.825
that displays the accumulated loyalty

00:00:36.825 --> 00:00:39.159
points, there is a section that contains

00:00:39.159 --> 00:00:42.909
the favorite drink of the customer. When I

00:00:42.909 --> 00:00:45.825
press Edit, I can change it. Now instead

00:00:45.825 --> 00:00:49.159
of my favorite coffee, let's try a script

00:00:49.159 --> 00:00:53.159
tag with some JavaScript. As soon as I

00:00:53.159 --> 00:00:56.159
press Submit, the JavaScript is executed.

00:00:56.159 --> 00:00:58.886
Now let's take a look at the code for the

00:00:58.886 --> 00:01:01.559
view for the loyalty overview page where

00:01:01.559 --> 00:01:04.759
the favorite drink is mirrored back to the

00:01:04.759 --> 00:01:07.659
user. The FavoriteDrink property of the

00:01:07.659 --> 00:01:11.444
model is surrounded by an Html.Raw call. I

00:01:11.444 --> 00:01:13.825
didn't put it there, of course, it was

00:01:13.825 --> 00:01:16.492
done by a colleague. With Html.Raw, you

00:01:16.492 --> 00:01:20.359
opt out of a security mechanism already in

00:01:20.359 --> 00:01:24.381
place in ASP.NET. It doesn't matter if you

00:01:24.381 --> 00:01:27.284
use Core or non-Core. When you remove

00:01:27.284 --> 00:01:29.492
Html.Raw, run the application again and

00:01:29.492 --> 00:01:32.158
wait for me to reenter the script tags,

00:01:32.159 --> 00:01:34.784
you can see the trick doesn't work

00:01:34.784 --> 00:01:37.158
anymore. The browser just shows the input

00:01:37.159 --> 00:01:40.159
instead of executing it as JavaScript.

00:01:40.159 --> 00:01:43.158
Let's take a look at the browser source of

00:01:43.158 --> 00:01:46.158
this web page and look for the script tag.

00:01:46.159 --> 00:01:49.659
MVC has now encoded the brackets around

00:01:49.659 --> 00:01:52.936
the word script, so the browser doesn't

00:01:52.936 --> 00:01:56.159
see it as JavaScript anymore. Unless you

00:01:56.159 --> 00:01:59.409
opt out explicitly by using Html.Raw, MVC

00:01:59.409 --> 00:02:02.301
uses this encoding to protect against

00:02:02.301 --> 00:02:06.444
these kinds of attacks. There's also an

00:02:06.444 --> 00:02:08.908
HTML helper called encode, which

00:02:08.908 --> 00:02:12.759
explicitly encodes text. You can use this

00:02:12.759 --> 00:02:15.959
helper when you have data that didn't go

00:02:15.959 --> 00:02:18.492
through MVC somehow. Because no matter

00:02:18.492 --> 00:02:21.159
which built-in safeguards are in place,

00:02:21.159 --> 00:02:24.358
you should still be very alert, especially

00:02:24.358 --> 00:02:26.659
when data is accepted from outside the

00:02:26.659 --> 00:02:30.159
normal model to view flow, like from

00:02:30.159 --> 00:02:33.270
cookies or local storage. ASP.NET has

00:02:33.270 --> 00:02:37.959
another NT XSS trick up its sleeve. On the

00:02:37.959 --> 00:02:40.359
loyalty overview page, the loyalty number

00:02:40.359 --> 00:02:43.301
is displayed. For some reason, the same

00:02:43.301 --> 00:02:45.409
colleague decided to take that value, not

00:02:45.409 --> 00:02:49.158
from the model, but from the query string.

00:02:49.159 --> 00:02:52.492
Attackers just try things, so they will

00:02:52.492 --> 00:02:55.659
also try to inject some JavaScript using

00:02:55.659 --> 00:02:59.034
the query string. ASP.NET attacks the

00:02:59.034 --> 00:03:02.492
potential malicious input by default. You

00:03:02.492 --> 00:03:05.492
can opt out of that too, but I wouldn't

00:03:05.492 --> 00:03:08.159
recommend it. Note that this detection

00:03:08.159 --> 00:03:13.909
only works with ASP.NET, not with ASP.NET

00:03:13.909 --> 00:03:18.016
Core. Back to browser protection, the

00:03:18.016 --> 00:03:20.825
X-XSS-Protection header was a way to

00:03:20.825 --> 00:03:23.742
instruct the browser to turn on XSS

00:03:23.742 --> 00:03:26.159
detection. The part before the colon, by

00:03:26.159 --> 00:03:29.284
the way, is a header type, and behind the

00:03:29.284 --> 00:03:32.587
colon is the header value. For this

00:03:32.587 --> 00:03:36.825
header, one enables XSS detection, and

00:03:36.825 --> 00:03:39.159
mode=block means that the page shouldn't

00:03:39.159 --> 00:03:43.444
be loaded at all when XSS is detected. But

00:03:43.444 --> 00:03:45.825
you should only use this header if you

00:03:45.825 --> 00:03:48.159
have to support all the browser versions

00:03:48.159 --> 00:03:51.284
that doesn't support Content Security

00:03:51.284 --> 00:03:55.409
Policy, or CSP. I'm going into CSP in the

00:03:55.409 --> 00:03:59.270
next clip. One thing it can do is block

00:03:59.270 --> 00:04:02.158
inline JavaScript, which makes the

00:04:02.158 --> 00:04:04.459
X-XSS-Protection header unnecessary. Once

00:04:04.459 --> 00:04:06.559
an attacker has found a vulnerability in

00:04:06.559 --> 00:04:09.730
your app, he or she will not use it to

00:04:09.730 --> 00:04:13.559
inject alert high in JavaScript text. The

00:04:13.559 --> 00:04:15.759
vulnerability will be exploited to read

00:04:15.759 --> 00:04:18.159
everything there is to read from your app,

00:04:18.159 --> 00:04:21.444
like the identity cookie of ASP.NET, which

00:04:21.444 --> 00:04:23.909
will give the attacker the ability to

00:04:23.909 --> 00:04:27.873
impersonate a user. A common scenario is

00:04:27.873 --> 00:04:31.159
that malicious scripts are loaded from the

00:04:31.159 --> 00:04:32.909
attacker's website to extract this

00:04:32.909 --> 00:04:35.958
information and send it to the attacker in

00:04:35.958 --> 00:04:38.659
an automatic way. Apart from the ability

00:04:38.659 --> 00:04:40.909
to block inline JavaScript, it would be

00:04:40.909 --> 00:04:43.659
great to stop the downloading of external

00:04:43.659 --> 00:04:46.758
JavaScript files and whitelist URIs that

00:04:46.758 --> 00:04:50.016
are okay to get JavaScript from. This is

00:04:50.016 --> 00:04:55.159
exactly where CSP comes in. CSP is the

00:04:55.159 --> 00:05:00.159
topic for the next clip.
