In the final video of this stage,

we're gonna look at cross-site request forgery, or CSRF.

CSRF was removed from the OWASP Top Ten in 2017,

falling out of the number eight spot from 2013.

Unfortunately, CSRF is still extremely common today,

with bug bounties claimed for CSRF on a daily basis.

For this reason, we will still cover CSRF in this course, but

don't be shocked when you don't see it on the OWASP Top Ten in 2017.

Without further ado, let's see what it's all about.

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 the vulnerable application processes as valid requests from the victim.

To carry it out, an attacker needs to get a user to visit a website or

app controlled by the attacker.

And then utilize the lack of CSRF protection on the target website to send

a request that'll perform some kind of state-changing action on the target site.

These kinds of actions can be things like sending money from the victim to

the attacker, or resetting the user's password.

Given this requirement, CSRF is as much a social engineering attack

as a traditional web application vulnerability.

And thus requires some amount of skill to set up.

Though this may sound hard, to trick a user today into clicking a button on

a site they may not find credible.

Attackers often set up sites that look exactly like the target site.

And then send a phishing email or

targeted advertising campaign to get unsuspecting users to fall for the trap.

To exploit CSRF, attackers leverage the fact that browsers

automatically send credentials, like session cookies,

with HTTP requests to the server from where those cookies were received.

Keep in mind, the victim must be logged-in to the vulnerable site, or

have a valid session token present in their browser.

As you might guess, our app is also vulnerable to CSRF.

Where an attacker can change the banking and

routing number in a user's profile, by getting the logged-in user to click on

a targeted link on a totally separate web site in their browser.

This attack consists of two parts.

First, we must set up a fake website in another domain where

we can send the forward request from.

To that end, we set up a site that advertises a banking

application with a sign-up for beta testing.

Let's log out and check out that site.

Within this site,

there's a form field which accepts an email, which we can see here.

However, if we dig into the source code, we see that this email is never submitted,

since there's no name attribute on the email input.

But there are two hidden fields.

When the form is submitted,

these hidden fields will be posted to the profile page of the target application.

This post will then update the banking and routing number of that user

to point to our attacker's banking and routing number, which is shown here.

We see that the action for

the form is the domain where the vulnerable app is running.

That's absolutely necessary to make this all work.

Well, if we simply post to the vulnerable site, and redirect the user there, they'll

probably think something is wrong, or they might even know they're being targeted.

To ensure this happens without fooling the victim user,

we've set up an empty iframe that'll ensure the attacker site

doesn't redirect to the target application when this form is submitted.

The iframe is also 0 width and 0 height, so the victim will never see it.

Okay, now onto the actual attack.

First, let's make sure that our victim user is logged into the vulnerable app.

Since the victim must have a valid session with the vulnerable site for this work.

Now, as the victim user, suppose we were sent an email, or

saw an ad for a revolutionary banking app, aptly named Revolution.

Little known to the victim, that's the site our attacker has set up.

And unfortunately, the victim is doing exactly what the attacker wants.

First, if we look at the profile page of the victim user,

we see that their banking and

routing numbers are 1234567, which right now is not the attacker's information.

Now, as the victim, we head to the Revolution banking app page, and

put in our email, and click Sign Up.

As the victim, nothing appears to have happened.

Except that we think we're now going to be on the shortlist for

getting our hands on the best banking tool since currency was invented.

However, if the CSRF attack was successful, we should now see that

the banking and routing numbers are updated to the attacker's information.

Specifically, a string of nines and eights, which came from the hidden fields

in the attacker's form on the Revolution site, let's look.

At this point, our attacker is free to transfer however much money out of

the victim's account as they want.

Or just continue to receive deposits that the victim thinks

are going to their account.

CSRF is bad news for your users, if you don't mitigate this issue.

Fortunately, effectively mitigating CSRF issues is one of the easiest fixes to

apply, compared to the other vulnerabilities we'll discuss.

Express's CSRF middleware provides a very effective way to deal with CSRF attacks.

By default,

this middleware generates a token that is added to requests that mutate state.

These are the put, post, and delete methods, or non-standard get methods.

The token can be added within a hidden form field, query string, or

a header field.

If you want to use other method of writing middleware, such as node csurf.

It's very important that the middleware providing CSRF protection is

initialized before any middleware that needs to know the method of the request.

Otherwise, an attacker can bypass that protection.

When the newly secured form is submitted, CSRF middleware will check for

the existence of the CSRF token.

It will validate that it matches the generated token for

the response-request pair.

If these tokens fail to match, the server will reject the request,

as it was likely forged.

By combating state-changing requests, and ensuring the requests are valid,

you can prevent CSRF.

In the context of our application, how do we prevent CSRF using this strategy?

Well, we can include the express CSRF middleware for

just this purpose in the main server file, server.js.

This is using the node csrf middleware, which generates new tokens for every new

request, and exposes the tokens to each state-changing request in the application.

Now this token can be included in a hidden form field, in the profile markup for

the profile page.

When someone tries to submit the form on the profile page,

if the request does not have the valid CSRF token.

Which would be the case if an attacker tried to submit a post to this form from

another website.

The request will then be dropped, and

no state changes will occur, preventing any sort of problems like we saw earlier.

Congratulations, you've now learned about, and

seen, command injection, cross-site scripting, and CSRF in action.

In the next stage, we're going to dive into application session-related

vulnerabilities like broken authentication.

And issues with access controls and sensitive data exposure.

See you soon.