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
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests that vulnerable application processes are legitimate requests from the victim.
New Terms:
- CSRF: Cross-Site Request Forgery forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application.
Further Reading:
OWASP on CSRF
Node.js CSURF
Preventing CSRF attacks in ASP.NET Core
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 final video of this stage,
0:00
we're gonna look at cross-site
request forgery, or CSRF.
0:01
CSRF was removed from
the OWASP Top Ten in 2017,
0:06
falling out of the number
eight spot from 2013.
0:09
Unfortunately, CSRF is still
extremely common today,
0:12
with bug bounties claimed for
CSRF on a daily basis.
0:16
For this reason, we will still
cover CSRF in this course, but
0:19
don't be shocked when you don't see
it on the OWASP Top Ten in 2017.
0:23
Without further ado,
let's see what it's all about.
0:26
A CSRF attack forces a logged-on victim's
browser to send a forged HTTP request.
0:29
Including the victim's session cookie,
and any other automatically included
0:36
authentication information,
to a vulnerable web application.
0:40
This allows the attacker to force
the victim's browser to generate requests
0:44
that the vulnerable application processes
as valid requests from the victim.
0:48
To carry it out, an attacker needs
to get a user to visit a website or
0:53
app controlled by the attacker.
0:57
And then utilize the lack of CSRF
protection on the target website to send
1:00
a request that'll perform some kind of
state-changing action on the target site.
1:04
These kinds of actions can be things
like sending money from the victim to
1:09
the attacker, or
resetting the user's password.
1:12
Given this requirement, CSRF is as
much a social engineering attack
1:16
as a traditional web
application vulnerability.
1:20
And thus requires some
amount of skill to set up.
1:22
Though this may sound hard, to trick
a user today into clicking a button on
1:24
a site they may not find credible.
1:28
Attackers often set up sites that
look exactly like the target site.
1:30
And then send a phishing email or
1:34
targeted advertising campaign to get
unsuspecting users to fall for the trap.
1:35
To exploit CSRF,
attackers leverage the fact that browsers
1:40
automatically send credentials,
like session cookies,
1:44
with HTTP requests to the server from
where those cookies were received.
1:47
Keep in mind, the victim must be
logged-in to the vulnerable site, or
1:52
have a valid session token
present in their browser.
1:56
As you might guess,
our app is also vulnerable to CSRF.
1:59
Where an attacker can
change the banking and
2:02
routing number in a user's profile,
by getting the logged-in user to click on
2:04
a targeted link on a totally
separate web site in their browser.
2:08
This attack consists of two parts.
2:12
First, we must set up a fake
website in another domain where
2:15
we can send the forward request from.
2:18
To that end,
we set up a site that advertises a banking
2:19
application with a sign-up for
beta testing.
2:22
Let's log out and check out that site.
2:25
Within this site,
2:27
there's a form field which accepts
an email, which we can see here.
2:28
However, if we dig into the source code,
we see that this email is never submitted,
2:31
since there's no name
attribute on the email input.
2:36
But there are two hidden fields.
2:39
When the form is submitted,
2:41
these hidden fields will be posted to the
profile page of the target application.
2:43
This post will then update the banking and
routing number of that user
2:47
to point to our attacker's banking and
routing number, which is shown here.
2:51
We see that the action for
2:55
the form is the domain where
the vulnerable app is running.
2:56
That's absolutely necessary
to make this all work.
2:59
Well, if we simply post to the vulnerable
site, and redirect the user there, they'll
3:02
probably think something is wrong, or they
might even know they're being targeted.
3:06
To ensure this happens without
fooling the victim user,
3:10
we've set up an empty iframe
that'll ensure the attacker site
3:13
doesn't redirect to the target
application when this form is submitted.
3:17
The iframe is also 0 width and 0 height,
so the victim will never see it.
3:20
Okay, now onto the actual attack.
3:25
First, let's make sure that our victim
user is logged into the vulnerable app.
3:27
Since the victim must have a valid session
with the vulnerable site for this work.
3:31
Now, as the victim user,
suppose we were sent an email, or
3:35
saw an ad for a revolutionary banking app,
aptly named Revolution.
3:39
Little known to the victim,
that's the site our attacker has set up.
3:42
And unfortunately, the victim is doing
exactly what the attacker wants.
3:46
First, if we look at the profile
page of the victim user,
3:50
we see that their banking and
3:53
routing numbers are 1234567, which right
now is not the attacker's information.
3:57
Now, as the victim, we head to
the Revolution banking app page, and
4:02
put in our email, and click Sign Up.
4:06
As the victim,
nothing appears to have happened.
4:08
Except that we think we're now
going to be on the shortlist for
4:11
getting our hands on the best banking
tool since currency was invented.
4:13
However, if the CSRF attack was
successful, we should now see that
4:17
the banking and routing numbers
are updated to the attacker's information.
4:21
Specifically, a string of nines and
eights, which came from the hidden fields
4:25
in the attacker's form on
the Revolution site, let's look.
4:28
At this point, our attacker is free
to transfer however much money out of
4:38
the victim's account as they want.
4:41
Or just continue to receive
deposits that the victim thinks
4:43
are going to their account.
4:46
CSRF is bad news for your users,
if you don't mitigate this issue.
4:48
Fortunately, effectively mitigating CSRF
issues is one of the easiest fixes to
4:53
apply, compared to the other
vulnerabilities we'll discuss.
4:57
Express's CSRF middleware provides a very
effective way to deal with CSRF attacks.
5:01
By default,
5:06
this middleware generates a token that
is added to requests that mutate state.
5:07
These are the put, post, and delete
methods, or non-standard get methods.
5:11
The token can be added within
a hidden form field, query string, or
5:15
a header field.
5:19
If you want to use other method of
writing middleware, such as node csurf.
5:21
It's very important that the middleware
providing CSRF protection is
5:25
initialized before any middleware that
needs to know the method of the request.
5:28
Otherwise, an attacker can
bypass that protection.
5:33
When the newly secured form is submitted,
CSRF middleware will check for
5:37
the existence of the CSRF token.
5:41
It will validate that it
matches the generated token for
5:43
the response-request pair.
5:45
If these tokens fail to match,
the server will reject the request,
5:47
as it was likely forged.
5:50
By combating state-changing requests,
and ensuring the requests are valid,
5:52
you can prevent CSRF.
5:57
In the context of our application, how
do we prevent CSRF using this strategy?
5:58
Well, we can include
the express CSRF middleware for
6:03
just this purpose in the main server file,
server.js.
6:07
This is using the node csrf middleware,
which generates new tokens for every new
6:41
request, and exposes the tokens to each
state-changing request in the application.
6:46
Now this token can be included in a hidden
form field, in the profile markup for
6:50
the profile page.
6:55
When someone tries to submit
the form on the profile page,
7:10
if the request does not
have the valid CSRF token.
7:13
Which would be the case if an attacker
tried to submit a post to this form from
7:16
another website.
7:19
The request will then be dropped, and
7:20
no state changes will occur, preventing
any sort of problems like we saw earlier.
7:21
Congratulations, you've now learned about,
and
7:26
seen, command injection,
cross-site scripting, and CSRF in action.
7:29
In the next stage, we're going to
dive into application session-related
7:34
vulnerabilities like
broken authentication.
7:38
And issues with access controls and
sensitive data exposure.
7:40
See you soon.
7:43
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