Part 5 CSRF Defenses

00:04

Hello and welcome to the cyber very secure coding course my name miss anywhere, and this is a lost top 10 for 2013

00:13

a eight cross site requests for tree

00:16

mitigations, countermeasures and defenses. So for a defenses overview, there are actually several things to to speak about.

00:27

First, we have to ensure that our particular Web application has no cross site scripting vulnerabilities.

00:37

Now this is indirectly related to see surf attacks,

00:41

so we need to ensure that we do our proper input validation. And, of course, our output in coding

00:50

now realize that the presence of cross site scripting

00:55

could defeat even your auntie si serve tokens.

00:59

And this could be through html. Http request calls

01:04

that would be used to capture responses and subsequent

01:11

NTC serve tokens that were signed there.

01:14

And then, of course, those tokens could be used in a crafted request

01:19

or could either be some other type of Ajax call.

01:25

Now, this does require a lot more work on the part of the attacker

01:33

to write the additional code, and it is a little bit beyond what we saw in the demos.

01:40

But this is certainly something that still could be considered and so

01:46

shows the importance of not having

01:49

a cross site scripting vulnerability.

01:53

Now, one thing that we're going to also speak about is how cross site scripting should not defeat challenge response defenses.

02:01

Challenge response defenses can be

02:06

exemplified in capture where you have to read the special characters before submitting a form.

02:13

Re authentication, of course, is where you're actually asking the owner

02:17

of the account for information

02:21

that only they should know.

02:23

And, of course, nonsense, which are one time passwords or hashed values that can be used

02:30

now, Auntie Caesar of tokens. That's probably the most prevalent way that see serve mitigations are performed.

02:39

Basically, the idea is you're going to generate and validate

02:46

a C serve token

02:47

on the server side. Anything that's generated on the

02:52

client side,

02:53

uh, or, um, originates from the client side from the browser. We know that we cannot trust,

03:00

and so you always want to make sure that the origin of your Auntie si serve token

03:07

is on the server side.

03:09

Now my recommendation is that you try to use built in framework, functions or methods first for creating anti seizure of tokens only because

03:21

they're gonna already have

03:23

the rain in number generator code in there for you. They're already going to

03:29

plot out all the steps that need to be done and so makes it a lot easier.

03:35

However, if that's not an option, you can always use awas c surfed open you till class. We're gonna take a look at some sample code in just a moment from that class. Now realize that you're into sea serve tokens. Got to be random. Remember how we talked about predictability of sea surf tokens? And so

03:54

if they are predictable or

03:57

if they don't change upon, log in, then they can be used in sea surf attacks.

04:03

You can check the entre P just as we saw in the demo to see just how strong your indices are. Token is

04:14

also, please make sure that you validate every request. Now, the monitoring of events is very important

04:19

in the

04:21

event that there is a potential see surf attack

04:26

meaning that on the service side there was some sort of mismatch between the token that was presented

04:33

and in the request and what was actually stored on the service side for that session

04:41

immediately. That transaction that request needs to be aborted,

04:47

and

04:48

it needs in the whole entire incident needs to be logged as a message

04:55

and alerted to either the Support or Dev Ops team

05:00

as a potential seats here for attack.

05:02

Now, if we take a look at some Ceasar of sample code here,

05:08

we can see that looking at the sea serve token, you till class from o us.

05:14

The first thing we're gonna do is generate our token on the server side. Now, this is done

05:18

through is overloaded,

05:20

get token methods. So I'm showing you one here where we're calling secure, random, and we get an instance of the suit. A random number, just random number, then gets placed into the web page

05:36

as part of the HDP response.

05:40

But it's also placed in the session object. And this is important. So you're gonna have your session object

05:46

that's available from your Web Web page as well as the session object that you're going to have on the service side. And so you need to make sure that the attributes in the session object from

06:01

from your client tear match. The attributes that are in your session object on the server side.

06:09

So you can see in the sample code. I've got a

06:12

hidden put type here that's going to store the anti seizure token.

06:17

And then finally, upon receipt of that token from the subsequent request, you're going to do the validation on the server side.

06:27

This can be done using this library

06:30

through the is valid method.

06:32

And so you can see there that

06:34

in your request object

06:38

if, in your request object you don't even have a session object created,

06:43

then you're automatically going to throw an exception

06:46

and terminate or abort that particular request.

06:50

And then you're going to generate a new token and start the process again.