So therefore let's dive right in
with the first attack pattern
to which our website could be vulnerable
and how it works.
We're going to perform it ourselves
and how we can then defend against it.
And we're going to start with this CSRF attack pattern.
Now see, CSRF stands for Cross Site Request Forgery,
and the idea here is, in the end,
that some malicious users,
some bad guy out there
simply creates a request that's sent to your back-end
that causes an action that shouldn't be performed.
And this might sound very abstract,
but forging such a request that then triggers such an action
is actually easier than you might first think.
Very often those CSRF attacks involve sessions
that are used in an unintended way
and such a request can, for example,
before forged by creating a website
that might look like your website
to which the bad guy then sends links
to possible users, who act as victims,
who basically use that website without knowing it,
for example, with phishing emails.
So with emails that are prepared to look
like they're officially coming from you
when they actually come from a bad guy,
and then those prepared websites could send
such a request using the user's session,
so to session of the victim who visited this prepared link,
to then send such a request,
such a forged request to the original back-end.
And to make that a bit clearer,
we're going to take a look at this exact attack pattern
in a concrete example that I prepared for you
where we will actually be able to launch our own attack
against our own website.
Now for that
I prepared some starting projects
and you'll find them all attached.
There's one zip file attached,
which gives you a folder with a couple of sub folders.
And these are different projects,
which we're going to visit
and use for all of this course section.
And we're going to start with this CSRF project.
And in that CSRF folder,
you're actually going to find two websites,
your own site,
which could be the real official site you're building;
and then the attacker's site,
which looks like your site but isn't your site.
I'll come back to that.
Let's first of all, have a look at our own site.
This is a fairly basic Node Express application,
very similar to what we built before in the course.
It's using authentication,
just as you learned it before in the course,
with cookies and sessions and so on.
And I'm using MongoDB as a data storage,
and also as a session storage.
And for this I have a database called security,
which will be used...
And of course, therefore, if you wanna follow along,
you should make sure
that your MongoDB server is up and running
so that this site can connect to it.
Now you can open your terminal here in View as code
and navigate into that CSRF folder with this CD command,
which stands for Change Directory,
this works on MacOS and Windows,
and then enter CD again, into the my-site folder.
So that any commands we're now going to run,
run from inside of that my-site folder.
And here we want to run NPM install
to install all dependencies
and then thereafter, NPM start,
and we can combine these two commands
and run them after each other
with the two and percent symbols here,
alternatively, you run them as two separate commands.
So this installs all dependencies and starts that server,
which connects to the MongoDB database
and which then listens on port 3,000.
That's what you can see in app JS,
we're listening on port 3,000.
With that up and running,
if you load local host 3,000
then you see your site here
and there we can log in with users.
However, we, first of all, have to create one.
And for this all, whoops,
quickly create a new user here
like this.
And now we can log in with that user which we just created
just as we learned it before in the course.
And here we are.
And once you are logged in,
you have this dummy Send Money page here
the slash transaction page.
This doesn't actually do anything,
it doesn't actually work.
It's just a dummy site here,
but let's assume that you're building some website
where users can send money to each other
by entering their email and then the amount.
Of course, it would be
typically a bit more complex than that,
but I wanna focus on the core functionality here
to show you the essence of the attack pattern,
which then could be applied to any website.
So here, let's say, we want to send money to test@test.com.
So I entered this here
and I wanna send $500 or whatever.
If I click send, I get this success message,
and if you open a MongoDB shell to look into your database
and you use the security database,
you should then be able to query the transactions collection
and find all transactions in there.
And here you should see the one transaction
that you just created with that website.
We're sending money from our account to this account.
And that's the email address I just entered
and that's the amount.
Of course, feel free to dive into the code for that
in the routes folder.
It's very straightforward though.
I'm just creating a basic document
and I'm inserting this into my transactions collection
and that's about it.
Nothing too fancy
and deliberately that's kept rather simple.
The rest of this page is basically the log in
and signup logic we already learned before.
So that's all working.
How could this now be attacked?
Well, as I said, for example, with such a CSRF attack,
and for this a user could build
a website that looks like our website,
and then that attacker could send an email
to people who are using our website,
and if those people click on the link,
they will see the prepared website of the attacker,
which looks like the correct website
so they don't necessarily see the difference,
but then if they send money,
actually the attacker will swap the recipient
for a different recipient,
and maybe also the amount,
and therefore steal money.
And that's of course,
then just one action that could be taken, stealing money.
The bad thing is that it's just an example
and this CSRF attack could be used
for any kind of action that's supported by the website.
And in this case,
sending money is the only supported action we have.
And that's the other project you have in a CSRF folder,
the attacker site.
This is all the simple note express website,
but I wanna emphasize
that the attacker doesn't have to use
the same technology we are using on our site.
The attacker just builds a site
that looks like our site
and how he or she does that is totally up to him or her.
And therefore that's a very simple Node Express site.
It doesn't have any sign up logic or anything like this
because that's not the goal of the attacker.
The attacker's goal is not to rebuild our site
with its functionality,
the goal is to rebuild the look of our site.
And for this, the attacker is mainly focused on
the transaction page here.
Therefore that's the only template I got here
and here the attackers stole
the HTML styling of the official site.
And of course it would be fairly easy to steal that
because all you need is the Browser DevTools.
And then I can see the markup
and I can see all the styling.
So rebuilding the look and feel of a site is really easy,
you don't need any hacking tools for that
the browser developer tools will do.
So rebuilding a site is fairly simple.
And then on this rebuild site, in this template here,
what the attacker is doing is
these two official form inputs,
which we have, don't have a name attribute
so if the form is submitted,
the values entered by the user will not be submitted.
Those inputs are only there to trick the user
and rebuild the look and feel of the official site.
Instead, we got two hidden inputs here,
which holds the actual values
the bad guy wants to use for sending the money to,
and for sending a concrete amount.
And of course, that's a very simple, basic example here,
but that is generally how those CSRF attacks
can be launched.
Now, the attack is altered in a way
that can't easily be seen by the website visitor,
to the website visitor it will not be obvious
that this site is not sending the values that are entered
by the visitor.
And the last but very important part
that was edited by the attacker on his fake site is
the URL to which the form is submitted.
That is the URL of your site
so that's the correct URL.
This is sent to your site so that is absolutely correct.
This is not lead into the attacker's site
because the attacker wants to create
a request that is sent to the official site,
it's just the action that's triggered by the request
that should be changed.
And that was changed with those hidden input values
because now a different amount of money will be sent
to a different person.
Now, can we send such a request from site A to site B?
Yes, by default we can,
and even if site B, so official site let's say,
requires authentication.
Because if the user is locked in,
which he or she needs to be to send that transaction,
but if the user is locked in
then the user has a cookie
with that session ID that belongs to the user
as you learned.
And if the browser sees a request being sent
to the site that issued a cookie
then the browser will attach the cookie to that request
even if the request is sent from a different site,
it's the target of the request
so to target URL that matters,
if that's the correct URL
the browser will attach to cookie
and therefore, the request the will arrive
on your official site with a correct cookie,
hence the user identity can be confirmed there
and now the request will be parsed on the official site
just with those bad input values.
And to show this to you
I'm going to keep my good,
my official server up and running,
but I'm also going to start the attackers server
because here I prepared that site
to listen on a different port.
And if you use a different port,
so local hosts 8,000 instead of local host 3,000,
that indeed acts as a totally different domain.
So that's the same as having examples of com
and mypage.com as domains.
Local hosts with different ports
are two totally different domains
and therefore we can use that
to simulate an attack from site A to site B.
Hence, I'll keep that terminal up and running
and I'll just open a new additional terminal.
And there again, we CD into the CSRF folder,
we CD into the attacker site folder
and we run NPM install and NPM starts there
to install all dependencies and start the server.
Now we can visit localhost/transaction,
that's the site the attacker might send us to.
So that's the link that might be included
in a phishing email that's sent to users
of that official site.
And here I added attacker in the URL
so it is a bit easier for us to tell the sites apart,
of course the attacker would not do that.
And if that would not be included, that attacker label here,
these sites would look exactly the same.
Of course you can remove it
to ensure that they do look the same.
So as a regular user,
I click on a link in an email
and I might end up on this attackers site.
And now I wanna send money to my friend,
the same email address and the same amount as before.
I can click send and I end up on Success,
now, by the way, on the official site,
because the request was sent to the official site,
that site issued a redirect
so now I am on that official site.
So now I don't even have a chance of seeing
that I was on the wrong site before
because I'm on the correct site now.
But if we now have a look
at all the transactions in the database,
we can see that here, we got a problem.
This indeed was sent to the wrong person,
and it's the wrong amount.
So this is the result of this forged request.
And that was a lot of talking,
but I want you to understand this pattern.
I want you to understand how such requests can be forged,
how they can be created, and which damage they can cause.
And as you can see,
that's quite a lot of damage
because now money might have been sent to a bad person.