Hello and welcome to the cyber very secure coding course my name miss anywhere, and this is a lost top 10 for 2013
a eight cross site requests for tree
mitigations, countermeasures and defenses. So for a defenses overview, there are actually several things to to speak about.
First, we have to ensure that our particular Web application has no cross site scripting vulnerabilities.
Now this is indirectly related to see surf attacks,
so we need to ensure that we do our proper input validation. And, of course, our output in coding
now realize that the presence of cross site scripting
could defeat even your auntie si serve tokens.
And this could be through html. Http request calls
that would be used to capture responses and subsequent
NTC serve tokens that were signed there.
And then, of course, those tokens could be used in a crafted request
or could either be some other type of Ajax call.
Now, this does require a lot more work on the part of the attacker
to write the additional code, and it is a little bit beyond what we saw in the demos.
But this is certainly something that still could be considered and so
shows the importance of not having
a cross site scripting vulnerability.
Now, one thing that we're going to also speak about is how cross site scripting should not defeat challenge response defenses.
Challenge response defenses can be
exemplified in capture where you have to read the special characters before submitting a form.
Re authentication, of course, is where you're actually asking the owner
of the account for information
that only they should know.
And, of course, nonsense, which are one time passwords or hashed values that can be used
now, Auntie Caesar of tokens. That's probably the most prevalent way that see serve mitigations are performed.
Basically, the idea is you're going to generate and validate
on the server side. Anything that's generated on the
uh, or, um, originates from the client side from the browser. We know that we cannot trust,
and so you always want to make sure that the origin of your Auntie si serve token
is on the server side.
Now my recommendation is that you try to use built in framework, functions or methods first for creating anti seizure of tokens only because
they're gonna already have
the rain in number generator code in there for you. They're already going to
plot out all the steps that need to be done and so makes it a lot easier.
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
if they are predictable or
if they don't change upon, log in, then they can be used in sea surf attacks.
You can check the entre P just as we saw in the demo to see just how strong your indices are. Token is
also, please make sure that you validate every request. Now, the monitoring of events is very important
event that there is a potential see surf attack
meaning that on the service side there was some sort of mismatch between the token that was presented
and in the request and what was actually stored on the service side for that session
immediately. That transaction that request needs to be aborted,
it needs in the whole entire incident needs to be logged as a message
and alerted to either the Support or Dev Ops team
as a potential seats here for attack.
Now, if we take a look at some Ceasar of sample code here,
we can see that looking at the sea serve token, you till class from o us.
The first thing we're gonna do is generate our token on the server side. Now, this is done
through is overloaded,
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
as part of the HDP response.
But it's also placed in the session object. And this is important. So you're gonna have your session object
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
from your client tear match. The attributes that are in your session object on the server side.
So you can see in the sample code. I've got a
hidden put type here that's going to store the anti seizure token.
And then finally, upon receipt of that token from the subsequent request, you're going to do the validation on the server side.
This can be done using this library
through the is valid method.
And so you can see there that
in your request object
if, in your request object you don't even have a session object created,
then you're automatically going to throw an exception
and terminate or abort that particular request.
And then you're going to generate a new token and start the process again.
So now we're gonna move into the lab portion of our module.