So these are CSRF attacks.
How can we protect against those attacks?
Well, of course, it's a good protection
if your site visitors don't click on phishing links.
We should all be careful when we get emails
and these emails contain links.
Sometimes you get emails
that something's wrong with your account
and you should now click this link.
And, of course, you click there
because you wanna fix your account
and that might've been a phishing email.
Well-made phishing mails can be hard to detect
and even phishing mails that are not that good.
If they're sent to thousands
or hundreds of thousands of people,
there is a good chance that some people click on them.
So even though it would be best
if people never fall for that trick, it will happen.
So you can't rely on your users
when it comes to defending against CSRF attacks.
Instead, you as the developer of a site
have to ensure that your site is protected against this.
And thankfully, it is rather simple
to protect against CSRF attacks.
The best practice protection against CSRF attacks
that you could add to your site
involves the creation of so-called CSRF tokens.
These are tokens, random-looking string values
that are generated on the server side
which are only known by the server,
which are a short lived,
they only exist for one request response cycle,
and which are known to the server
because the server generated those tokens.
Now, those tokens, so those strings are then injected
into the templates that are rendered by the server,
for example, in a hidden input field.
And then for incoming requests,
the server checks whether such a valid token
is part of that request.
Since only the server knows these tokens,
since they are only valid
for one incoming request thereafter,
and since they therefore only exists
in the official templates,
in the official pages rendered by that server
that's owned by you,
an attacking server, a faked server,
can't know those tokens.
They can't be guessed.
They can't be generated by that other server.
Only your server knows the correct tokens
and they can't be stolen.
And therefore, requests without a valid CSRF token
will be blocked and hence this attack pattern,
which I just showed you, won't work.
Now, you can implement this defense
with all server-side programming languages,
with PHP, C#, whatever it is,
but you can also do it with Node Express.
And if you search for Express CSRF,
you'll find some packages,
some third-party packages which you can use,
which will simplify your life.
The csurf package is the most popular one
for Node Express apps.
And therefore, that's the one I'll use here.
In my first terminal window,
where I'm running the official server,
I'll quit that server
and I will install the csurf package here.
Now, we can activate it in the my-site folder in app.js.
And here, we wanna import CSRF
by requiring csurf, this package.
And then we have to register it as a middleware.
Now, I'll activate that after activating the session
because the CSRF package uses sessions under the hood.
And I'll activate it by using app.use
as I did it before in the course.
And then we execute CSRF as a function
and you can configure it.
More details can be found in the official documentation,
but the default options should actually do the trick.
So no special configuration is required here.
So activating the package here is the first step,
and now we can use it in our routes.
Here in all the routes that return pages that contain forms,
you should add such a CSRF token
because it's these pages that contain forms
that can be rebuilt and manipulated by attackers
as you saw it before.
So, for example here, when we get to the transaction page,
which is that page that contains the form,
we wanna ensure that we generate and use such a CSRF token.
For this in this get route, we can add a CSRF token constant
and generate that token by using the request object
and then there, the CSRF token function.
This is a function or a method
that's provided by the csurf package we just installed.
And this will generate such a token,
which I talked about before,
which will be stored by the package
for one request response cycle on the server
with help of sessions.
Next, we send that token into our template,
for example like this,
so that in the template, we can use this token,
which is just a string in the end.
So in that transaction.ejs file,
we now wanna add a hidden input in that form.
And you wanna do that for every form on your page.
There, you wanna add an input of type hidden
because it's not an input
where the visitor should enter a value.
Instead, we will add our own value
and that value is that CSRF token.
And I'll inject it here with that ejs syntax
because we passed it to the template
a couple of seconds ago.
Now, this hidden input needs to have a special name
and that special name is _csrf.
That's the name the CSRF package,
or the csurf package in this case,
will look for when that request is submitted.
And it will automatically look for that field.
You don't need to write any extra logic for that.
That instead will be done automatically
by the csurf middleware that we activated.
But with that, this form on the official site
now will contain this token
and the form on the attacker's site won't
because the attacker has no way
of getting this correct token
because that token is generated on the official site
and therefore only known to that site.
So now if we restart the server here
and I'm back on the official site,
I can reload and if I sent money to test3@test.com,
let's say 300, this works.
This still works.
You just have to make sure you reload at least once
before you send it
because only then the updated template will be used.
But now with that, that was sent.
And if we have a look at all transactions,
we can see that latest transaction
with the correct recipient here.
If I'm now back on the attacker page here,
local host 8000/transaction,
and I try the same trick from before again,
now we have an error.
Now we have an error
and now we don't have that transaction here.
Instead, no new transaction was added
because that attacker page was missing the token,
the CSRF token.
So this is how you defend against those CSRF attacks.
You wanna include this token into all your forms
with help of that CSRF package.
Now here, we also would have more forms
where we can add signup and login.
And therefore, definitely as an extra practice,
add the token there.
I will instead move on to the next attack pattern,
but later in this course,
when we work on the online shop example,
we will, of course,
also implement CSRF protection there again.