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