WEBVTT

0:00:03.900000 --> 0:00:06.600000
 Hello everyone and welcome to this video.


0:00:06.600000 --> 0:00:10.700000
 In this video we're going to be exploring
 cross-side request forgery attacks.

0:00:10.700000 --> 0:00:14.100000
 Now this is a vulnerability that I'll
 assume you have some experience

0:00:14.100000 --> 0:00:20.420000
 with and again if you have gone through
 the EWPT learning path and certification

0:00:20.420000 --> 0:00:22.160000
 you should be familiar with it.

0:00:22.160000 --> 0:00:25.820000
 So my job or my objective in this video
 is to sort of revisit cross-side

0:00:25.820000 --> 0:00:33.260000
 request forgery just for the sake of
 again reminding you what it is as

0:00:33.260000 --> 0:00:38.440000
 a vulnerability, what causes it and
 how this vulnerability is typically

0:00:38.440000 --> 0:00:41.980000
 exploited. The other reason why I think
 it's important is because we've

0:00:41.980000 --> 0:00:48.040000
 sort of gone over quite a few session
 management tests or techniques and

0:00:48.040000 --> 0:00:51.820000
 by this point you need to sort of get a
 grasp of a majority of them otherwise

0:00:51.820000 --> 0:01:01.200000
 you start mistaking one for the other
 because they sort of work in sort

0:01:01.200000 --> 0:01:05.940000
 of a similar way if you will with regards
 to the fact that they all involve

0:01:05.940000 --> 0:01:08.080000
 session IDs to a certain extent.

0:01:08.080000 --> 0:01:12.580000
 So I always think it's important to always
 revisit some of these vulnerabilities

0:01:12.580000 --> 0:01:17.920000
 and sort of refresh yourself
 or refresh your memory.

0:01:17.920000 --> 0:01:21.920000
 We'll also be looking at a practical example
 during the practical demonstration

0:01:21.920000 --> 0:01:26.980000
 section of this video but without further
 ado what is cross-side request

0:01:26.980000 --> 0:01:32.200000
 forgery? Well cross-side request forgery
 abbreviated as CSRF is a type

0:01:32.200000 --> 0:01:36.260000
 of web security vulnerability that occurs
 when an attacker tricks a user

0:01:36.260000 --> 0:01:40.780000
 into performing actions on a web application
 without their knowledge or

0:01:40.780000 --> 0:01:45.480000
 consent. So this vulnerability or attack
 takes advantage of the trust

0:01:45.480000 --> 0:01:49.200000
 that a web application has
 in the user's browser.

0:01:49.200000 --> 0:01:53.180000
 Now in the context of a web application,
 you know, in the context of web

0:01:53.180000 --> 0:01:57.960000
 application penetration testing, understanding
 CSRF or cross-side request

0:01:57.960000 --> 0:02:02.300000
 forgery is crucial for identifying and
 mitigating this as a you know as

0:02:02.300000 --> 0:02:06.520000
 a potential risk because the only way
 to tell if a web application is

0:02:06.520000 --> 0:02:12.240000
 indeed vulnerable to CSRF requires you
 to test for it and this the reason

0:02:12.240000 --> 0:02:15.520000
 why I'm stating this explicitly in the
 case of this vulnerability is with

0:02:15.520000 --> 0:02:20.700000
 the others you can pretty much get an
 indication very early on that yeah

0:02:20.700000 --> 0:02:26.220000
 you know a session fixation vulnerability
 probably exists without even

0:02:26.220000 --> 0:02:32.980000
 testing for session fixation you sort
 of are at around 70 or 60 percent

0:02:32.980000 --> 0:02:34.280000
 you know certainty.

0:02:34.280000 --> 0:02:39.480000
 However with CSRF the only way to you
 know to verify you know whether

0:02:39.480000 --> 0:02:43.720000
 a site is indeed vulnerable to CSRF
 or not is to actually test for it.

0:02:43.720000 --> 0:02:48.780000
 So how does this work what
 does the attack look like?

0:02:48.780000 --> 0:02:54.060000
 So in a CSRF attack the attacker crafts
 a malicious request and tricks

0:02:54.060000 --> 0:02:59.660000
 a user into unknowingly sending that request
 to a vulnerable web application.

0:02:59.660000 --> 0:03:03.480000
 Now web applications typically trust
 that requests coming from a user's

0:03:03.480000 --> 0:03:09.060000
 browser are legitimate however CSRF exploits
 this trust so most web applications

0:03:09.060000 --> 0:03:11.840000
 use cookies for user authentication.

0:03:11.840000 --> 0:03:18.900000
 When a user identifies them during you
 know their session or when they're

0:03:18.900000 --> 0:03:20.440000
 logged in as it were.

0:03:20.440000 --> 0:03:25.380000
 Now this cookie is automatically sent with
 every request to the web application.

0:03:25.380000 --> 0:03:30.960000
 So what the attacker does is the attacker
 crafts a malicious request for

0:03:30.960000 --> 0:03:36.360000
 example changing the user's email address
 or password and then embeds

0:03:36.360000 --> 0:03:40.560000
 that particular request or code if you
 will that facilitates this malicious

0:03:40.560000 --> 0:03:45.180000
 request into a web page email
 or some other form of content.

0:03:45.180000 --> 0:03:48.680000
 The bottom line is that you know you
 send this to the victim somewhere

0:03:48.680000 --> 0:03:54.420000
 or another and then the attacker you
 know lowers the victim into loading

0:03:54.420000 --> 0:03:58.920000
 this content while the victim is authenticated
 into the target web application

0:03:58.920000 --> 0:04:02.880000
 right. So what happens is that the victim's
 browser automatically sends

0:04:02.880000 --> 0:04:08.000000
 the malicious request including the
 victim's authentication cookie and

0:04:08.000000 --> 0:04:11.840000
 the web application trusting the request
 due to the authentication cookie

0:04:11.840000 --> 0:04:16.540000
 processes it causing the victim's account
 to be compromised or to be modified

0:04:16.540000 --> 0:04:20.080000
 or you know the account to essentially
 perform certain actions.

0:04:20.080000 --> 0:04:24.140000
 So the easiest way of explaining this
 is you know for example within a

0:04:24.140000 --> 0:04:28.480000
 web application we can take the password
 reset form when you're logged

0:04:28.480000 --> 0:04:33.360000
 in. If we are to sort of take the fields
 that that form uses and we set

0:04:33.360000 --> 0:04:37.420000
 up a duplicate page or you know sort of
 a clone of that page on a different

0:04:37.420000 --> 0:04:45.940000
 web server within that particular or
 you know we can take another example

0:04:45.940000 --> 0:04:52.120000
 it could just be a standard web page on
 a server that the attacker controls.

0:04:52.120000 --> 0:04:56.780000
 The bottom line is that you know either
 through purchasing a domain that

0:04:56.780000 --> 0:05:00.940000
 looks awfully similar to the target
 web application's domain or through

0:05:00.940000 --> 0:05:07.880000
 some other social engineering techniques
 we somehow get the victim to

0:05:07.880000 --> 0:05:13.260000
 click on this link and that link again
 essentially takes the victim to

0:05:13.260000 --> 0:05:17.860000
 a domain or the IP address of a server
 that contains this malicious code

0:05:17.860000 --> 0:05:22.140000
 typically you know using HTML,
 JavaScript, PHP, etc.

0:05:22.140000 --> 0:05:31.940000
 That code is configured specifically
 to utilize the victim's session ID

0:05:31.940000 --> 0:05:35.960000
 or cookie and then send a request to
 the actual target web application

0:05:35.960000 --> 0:05:42.060000
 to do something that you know whatever
 you want to be able to accomplish

0:05:42.060000 --> 0:05:47.280000
 is entirely up to you and again the
 best way of understanding CSRF is

0:05:47.280000 --> 0:05:50.940000
 to actually take a look at it or take
 a look at a practical example and

0:05:50.940000 --> 0:05:53.500000
 that's what we're going to be doing
 in a few seconds and I think it'll

0:05:53.500000 --> 0:05:55.760000
 make it a whole lot easier
 for you to understand.

0:05:55.760000 --> 0:05:59.860000
 So the bottom line is that CSRF attacks
 can have serious consequences

0:05:59.860000 --> 0:06:04.440000
 but most importantly you know unauthorized
 changes to a user's account

0:06:04.440000 --> 0:06:08.900000
 settings, fun transfers or actions
 on behalf of the user without their

0:06:08.900000 --> 0:06:13.000000
 consent, malicious actions like changing
 passwords, email addresses or

0:06:13.000000 --> 0:06:15.620000
 profile information.

0:06:15.620000 --> 0:06:19.600000
 So with that being said now that you sort
 of have you know you've refreshed

0:06:19.600000 --> 0:06:25.240000
 your memory or about CSRF don't worry
 I still think you should be able

0:06:25.240000 --> 0:06:29.760000
 to get the idea or the gist of the vulnerability
 you know during the practical

0:06:29.760000 --> 0:06:32.620000
 section which we are now getting into.

0:06:32.620000 --> 0:06:36.400000
 So this video has a lab associated with
 it and the lab is just going to

0:06:36.400000 --> 0:06:38.580000
 be below this video.

0:06:38.580000 --> 0:06:42.020000
 This lab will not provide you with access
 to a pre-configured Kali Linux

0:06:42.020000 --> 0:06:46.620000
 system so you'll have to end up using
 your own virtual machine or if you

0:06:46.620000 --> 0:06:50.080000
 have burpsuit installed on your host
 operating system that'll work just

0:06:50.080000 --> 0:06:53.100000
 as fine that's really the only thing you
 need is a web browser and burpsuit

0:06:53.100000 --> 0:06:59.260000
 or even zap you know have your pick of
 tools as long as you can intercept

0:06:59.260000 --> 0:07:02.860000
 a request modify a request
 you should be good to go.

0:07:02.860000 --> 0:07:08.220000
 Anyway I'm going to fire up my lab and
 I'll see you in my Kali Linux virtual

0:07:08.220000 --> 0:07:11.000000
 machine in a couple of seconds.

0:07:11.000000 --> 0:07:15.520000
 All right so I'm currently in my Kali
 Linux virtual machine and as you

0:07:15.520000 --> 0:07:19.760000
 can see I've already opened up the target
 web application that'll be provided

0:07:19.760000 --> 0:07:23.380000
 to you or whose address will be provided
 to you when you start the lab

0:07:23.380000 --> 0:07:27.540000
 in burpsweets browser ready to intercept.


0:07:27.540000 --> 0:07:31.660000
 So immediately when you click on the lab
 link it'll open up a web application

0:07:31.660000 --> 0:07:35.760000
 that is called PHP ticket system that
 prompts us immediately to log in

0:07:35.760000 --> 0:07:39.360000
 with our email and password right.

0:07:39.360000 --> 0:07:43.960000
 Now before we do anything you know
 in order to sort of streamline this

0:07:43.960000 --> 0:07:50.880000
 demonstration this particular system
 or web application has you know some

0:07:50.880000 --> 0:07:55.960000
 publicly disclosed vulnerabilities
 so we can utilize search sploit to

0:07:55.960000 --> 0:08:03.960000
 look for ticket the PHP ticket system
 so something like this and we can

0:08:03.960000 --> 0:08:07.400000
 see right over here there's the vulnerability
 so PHP ticket system beta

0:08:07.400000 --> 0:08:11.620000
 1 cross-site request forgery and I'll
 just navigate to my desktop here

0:08:11.620000 --> 0:08:19.200000
 and I'll copy that particular poc text
 file exploits and we want this

0:08:19.200000 --> 0:08:27.780000
 one right over here so the path is just
 PHP web apps to 607 so I'll just

0:08:27.780000 --> 0:08:31.560000
 paste that in there and then I'll copy
 it to my desktop right over here

0:08:31.560000 --> 0:08:42.540000
 so I'll now approve the concept so
 the exploit title PHP ticket system

0:08:42.540000 --> 0:08:47.780000
 cross-site request forgery and in this
 case the CSRF allows us to reset

0:08:47.780000 --> 0:08:52.480000
 admin password via CSRF so this means
 that it'll only work on admin account.

0:08:52.480000 --> 0:08:56.880000
 Now within the lab documentation you've
 already been provided with access

0:08:56.880000 --> 0:09:01.640000
 to the admin credentials in order to
 essentially facilitate the attack

0:09:01.640000 --> 0:09:07.560000
 so because again the admin would need
 to be authenticated so the username

0:09:07.560000 --> 0:09:11.920000
 and password has been provided to simulate
 you know the attack the victim's

0:09:11.920000 --> 0:09:22.020000
 side of the attack so the username admin
 password is 12321 login so remember

0:09:22.020000 --> 0:09:25.800000
 the target needs to be authenticated
 because remember this is all based

0:09:25.800000 --> 0:09:32.180000
 on the session ID or you know the authenticated
 session cookie and the

0:09:32.180000 --> 0:09:39.700000
 information contained they're in so
 it actually gives us the CSRF code

0:09:39.700000 --> 0:09:43.200000
 that we can use to facilitate this
 and you can see it right over here

0:09:43.200000 --> 0:09:48.540000
 and in this particular case I think
 we would need to clean this so if

0:09:48.540000 --> 0:09:56.220000
 I just say Vim what's let me see if
 I can open this up in Vim so looks

0:09:56.220000 --> 0:09:59.800000
 like it already has line numbering which
 is kind of annoying but we can

0:09:59.800000 --> 0:10:08.520000
 I think we can clean this up so let me
 open this up in mousepad so desktop

0:10:08.520000 --> 0:10:13.880000
 that's the one there and what we want
 I'll just zoom in so you can see

0:10:13.880000 --> 0:10:20.300000
 this is just this over here so we want
 to create an HTML file and then

0:10:20.300000 --> 0:10:25.360000
 host it on our web server that attacker
 controls that is not necessarily

0:10:25.360000 --> 0:10:29.360000
 on a web server because it's HTML but
 you know I'll just create a new

0:10:29.360000 --> 0:10:36.880000
 file here and now you need to get rid
 of the line numbers here so we had

0:10:36.880000 --> 0:10:39.760000
 rid of that there I'm just going to
 clean this up and I'll get back to

0:10:39.760000 --> 0:10:46.520000
 you when this is done all right so I
 am done and as you can see this is

0:10:46.520000 --> 0:10:51.840000
 what it does so it takes advantage of
 the we want to need to replace the

0:10:51.840000 --> 0:11:00.560000
 IP here in this particular case we just
 want this right over here so let

0:11:00.560000 --> 0:11:07.960000
 me replace this one here action there we
 are just to this point the parameter

0:11:07.960000 --> 0:11:12.060000
 is going to be process change password
 and then ID is equal to one so

0:11:12.060000 --> 0:11:19.040000
 that's the user ID not the session ID
 so just modify that there and what

0:11:19.040000 --> 0:11:24.640000
 this is doing is again if you were
 to send or if the admin were to get

0:11:24.640000 --> 0:11:29.660000
 or visit this page whether it's hosted
 on a web server that you own or

0:11:29.660000 --> 0:11:33.980000
 whatever and this was processed by
 their browser it would essentially

0:11:33.980000 --> 0:11:40.940000
 make a request to reset the admin user's
 password on the actual web application

0:11:40.940000 --> 0:11:45.560000
 in this case PHP ticket system and
 change it to whatever value that we

0:11:45.560000 --> 0:11:50.780000
 wanted so I can just set it to Alexis
 for example right so new password

0:11:50.780000 --> 0:11:57.260000
 confirm password there we are so what
 we need to do now let's just save

0:11:57.260000 --> 0:12:04.420000
 this as so you know my desktop we'll
 call it CSRF.html and save it like

0:12:04.420000 --> 0:12:10.260000
 so there we go and now again we're not
 going to set up our own web server

0:12:10.260000 --> 0:12:15.240000
 but what you do is you get a VPS or
 web server and host that HTML file

0:12:15.240000 --> 0:12:19.540000
 and then somehow send that link to the
 admin and you'd also need the admin

0:12:19.540000 --> 0:12:23.380000
 to be logged in or to have an authenticated
 session on the target web

0:12:23.380000 --> 0:12:26.500000
 application where this action is to
 be performed or where the password

0:12:26.500000 --> 0:12:33.040000
 reset is to be performed so let's say
 the attacker gets it and I'm just

0:12:33.040000 --> 0:12:42.240000
 going to we'll do this with Firefox so
 I'll just navigate here and there's

0:12:42.240000 --> 0:12:51.200000
 a reason for that so let me open up
 Firefox and paste and go we'll give

0:12:51.200000 --> 0:12:56.640000
 this a few seconds here so there we
 go so remember the original password

0:12:56.640000 --> 0:13:02.380000
 was 1 2 3 3 2 1 okay and I've changed
 it or I wanted to be Alexis right

0:13:02.380000 --> 0:13:06.900000
 so I'll just save that just to show
 you so let's say the admin let's say

0:13:06.900000 --> 0:13:12.500000
 I'm the admin and then someone sends
 me this very mighty interesting link

0:13:12.500000 --> 0:13:17.740000
 and we're going to open this up with
 Firefox and let's say I click on

0:13:17.740000 --> 0:13:24.240000
 the link and there we go it says submit
 form interesting and you know

0:13:24.240000 --> 0:13:27.980000
 we can get rid of this you know this
 should not be displayed obviously

0:13:27.980000 --> 0:13:31.420000
 don't want a victim saying their password
 has been changed but the bottom

0:13:31.420000 --> 0:13:40.800000
 line is I'm still logged in but you
 know if I were to if I were to log

0:13:40.800000 --> 0:13:51.740000
 out all right and I'll say admin and
 my old password the that's incorrect

0:13:51.740000 --> 0:13:55.540000
 it's not working but if I say admin
 and the password that I the attacker

0:13:55.540000 --> 0:14:01.660000
 specified as the new password being
 Alexis I hit login and there we go

0:14:01.660000 --> 0:14:05.440000
 and I don't know if there's a way I
 can show you this most likely I can

0:14:05.440000 --> 0:14:11.760000
 if I go in here let me go into my setting
 just to show you that the password

0:14:11.760000 --> 0:14:18.280000
 was indeed changed to Alexis so passwords
 where's my password manager

0:14:18.280000 --> 0:14:25.220000
 there we are so save logins view this
 here there we are you can see Alexis

0:14:25.220000 --> 0:14:31.600000
 so that's pretty much CSRF in a nutshell
 hopefully this example this demonstration

0:14:31.600000 --> 0:14:35.260000
 gave you a better idea as to how it
 works or sort of refresh your memory

0:14:35.260000 --> 0:14:38.620000
 obviously I know you might might have been
 a little bit confused but remember

0:14:38.620000 --> 0:14:43.320000
 to in order to show you these attacks
 that require let's say the involvement

0:14:43.320000 --> 0:14:47.500000
 or the interaction of another separate
 user I have to take the role of

0:14:47.500000 --> 0:14:51.760000
 the other user in this case I took
 the role of the the account we were

0:14:51.760000 --> 0:14:56.700000
 trying to get this you know this action
 performed on in this case will

0:14:56.700000 --> 0:15:01.680000
 be the admin so that brings us to the
 end of the practical demonstration

0:15:01.680000 --> 0:15:09.000000
 section of this video all right so
 that was cross-site request forgery

0:15:09.000000 --> 0:15:14.380000
 hopefully you gained a lot from that
 and you know there's really nothing

0:15:14.380000 --> 0:15:19.820000
 much to add to this particular video
 and you know that brings us to the

0:15:19.820000 --> 0:15:24.080000
 end of this video so thank you very
 much for watching we're now going

0:15:24.080000 --> 0:15:27.140000
 to be moving on to the next section
 of the course and with that being