Now after exploring CSRF attacks,
let's move on to XSS attacks.
XSS stands for cross-site scripting,
so the X stands for a cross
because, well, it looks like a cross.
And cross-site scripting attacks
are all about injecting malicious JavaScript code
into the content of a website.
So we've got our typical setup
let's say where we have a backend,
maybe talking to a database or some other data storage,
and we've got a client,
so a browser requesting a website from our backend,
from our server,
and then some website is displayed in that browser.
Now, the content that is displayed
will very likely be fetched from our database
or from some other data store.
So the server, the backend, renders let's say a template
and therefore produces HTML code
which is shown to the user, to the visitor in the browser
and that content that is rendered,
so the content of the generated HTML file
is very likely fetched from some data source.
For example, if you're building a blog,
then the blog posts, the list of blog posts,
and the individual blog posts
are coming from a database, for example.
That's what we built before in the course already.
Now with an XSS attack, as an attacker,
we try to sneak some malicious JavaScript code
into the content that will be part of that generated page
so that this rendered HTML page
contains malicious browser side JavaScript code
which is therefore executed when that page loads
in the browser of a visitor.
And therefore, it executes for every visitor
in their browsers.
And since browser side JavaScript is very powerful,
for example, you could use it to send Ajax requests
and then send all kinds of requests
to again send money or anything like that,
this is a real problem.
Now, again, I prepared a project here
into which we'll take a look
where I will show you this attack pattern
and what the problem with it is.
It's in this XSS folder which was part of the project
you found attached earlier in this course section.
And in there, you got another Node Express application.
Again, cross-site scripting attacks
are not exclusive to Node Express though.
Any website can be vulnerable to that.
And here, we got a very basic site.
We, for example, don't have authentication in there anymore
because it really doesn't matter.
Now, if your site does have authentication,
then XSS might be able to do even more damage
because with that injected JavaScript code,
you would be able to, again, send requests
on behalf of the authenticated users to,
for example, send money somewhere.
But again, it's not technically required.
Authentication is not technically required
to be vulnerable to XSS.
And therefore, here for simplicity reasons,
to keep that code a bit more simple,
I actually omitted authentication.
But with or without it, you can have XSS vulnerabilities.
Now, if we have a look at the routes we get,
it's very simple.
I just got three routes in here,
one for redirecting to /discussion.
And on the discussion page,
I'm fetching a bunch of comments from a comments collection.
Again here, I'm using MongoDB.
So if you wanna follow along,
you need to have MongoDB up and running.
And then here in the post route,
we actually handled a submission of a new comment
and then it's added into the database.
And the dummy website we're building here
is a very simple discussion platform
where users can submit comments
and see the comments of others.
In the views, I only got one main view here
and that is a view where I output all the submitted comments
and where I have a form for sending a new comment.
As a side note,
here you should definitely also add that CSRF token
because every website should protect against CSRF
and therefore every form in every website
should have a CSRF token.
I just don't have it here because with this example,
I'll specifically focus on XSS,
but you definitely would want to have your CSRF token here.
So that is a must have for every website
and we'll see it again later in the big course project
which we'll build.
But for the moment,
let's focus on cross-site scripting attacks.
And to show you how that works,
again, I'll open this integrated terminal in VS Code
and I'll navigate into the XSS folder.
And there we can run npm install
to install all dependencies
and then npm starts to start this server.
If you now go to local host 3000/nothing,
you'll be redirected to /discussion.
And there, you should be able to submit new comments
and then you see the comments here.
Again, it's a very basic site, definitely not fancy at all,
but this is really not about the styling
or anything like that.
I just wanna show the basic attack patterns.
Now here, we got this form
and what happens on this site is, of course, these comments,
which are output here, are user generated content.
All these comments are generated by users,
so we take some user input
and we then save that in a database
and then we serve that user input back to our visitors.
And, of course, all visitors would see these comments here,
not just the visitor who left the comment.
And even if you had authentication in place,
then maybe not all visitors are able to send a comment.
They might need to log in first,
or maybe they can't all see the comments.
They might need to log in for that as well.
But in the end, if they are logged in,
they might have that same behavior, which you see here,
which is why I omitted the authentication process
because it simply doesn't help us here
because the attack pattern, which I'll show you,
will work either way.
What if I don't enter some plain text here,
but I decided to create a script here.
I write some script code and here I'll just send an alert
where I say hacked like this.
This is valid JavaScript code.
And now I'll create a comment that contains that code.
Of course, this alert isn't doing anything fancy.
Indeed, it will actually show visitors
that something is fishy on this page if they load the page,
but it's just here to show you
that executing such scripts on a page might work.
In reality, you would probably not show an alert here,
but maybe send an Ajax request,
which then could also use your session
because cookies also get sent along with Ajax requests
and which then would actually also not be guarded
by your CSRF protection because if this script
would send an Ajax request,
then the script runs on the correct page and therefore,
it has the CSRF token because unlike with the CSRF attacks
I showed you before, now we're adding some code here
which will not run on a different page,
which doesn't know the CSRF token,
but I'm about to add some code here
which will be part of that same official page
which all visitors will visit.
And therefore, it will have access to the CSRF token,
which would be part of a hidden input field, for example.
But let's take a step back
and let's send this and see what happens.
You see, I got this alert here.
I got it once the page reloaded,
and here we see a second blog post
which doesn't seem to have any visual content,
but if we inspected with the browser dev tools,
we can see that in there in the second list item,
I got this script and this got executed.
And again here, I just used it to show an alert
to prove that it works,
but we could be doing far worse things in there,
like sending an Ajax request to some route of this page.
And since we have the cookie
and the CSRF token and everything, that could work
and we would have no protection against this.
That's why cross-site scripting attacks are super dangerous
because they run on your site.
They run on the official site and they run there
because some user managed to inject
some malicious JavaScript code into your page.
And you are vulnerable to this attack
whenever you're outputting user generated content.
Whenever users submit posts or comments
or news or whatever it is
and you then have a part of your page
that outputs that content,
you have a potential vulnerability.
And I'm not just talking about complete blog posts.
Whenever anywhere on your page
you're outputting any user generated content,
you have this potential vulnerability.