Now that we know how to discover and exploit Exaro vulnerabilities, let's talk about how to protect
websites from them.
So if we just go back now to DVDs and send the security to high, you'll see that they have a very simple
way to protect against it.
But this way actually works.
And what they do is they ask you for the current password.
So even if we get this form and we do all the forging and all the stuff that we were doing and then
send it to the target person, we can't actually hide this and get it to automatically submit because
we don't know the current password.
So it asks for the current password and then it allows you to add a new password.
So this is a really good solution for this case only, though, because what if the form actually doesn't
change a password?
What if we're just going to send messages pretending to be that person?
What if we're going to post things to that person's wall?
What if we're going to post things into that person's blog so Sarraf can be exploited to do many things,
as I said in previous videos.
And this method will only protect against changing the password.
You can't really ask the person for their password every time that they want to post something or to
do something with their profile.
Now, newer versions of DVDs that don't come with me to exploit the will to actually have a more secure
option that will implement the method that I'm going to talk to you about it now, it's actually called
impossible instead of high, but it doesn't matter.
It's not exploitable anyway, so we don't really need to have it installed.
So let's talk about how you could actually prevent these vulnerabilities from happen without asking
the user to re-enter information or to re-enter the password, if you think of it, the way we were
able to exploit this is we were able to just copy the form that the website uses and send it to the
target person and get that person to run it or automatically run on the target person's computer.
So once the request is sent to the server, the server wasn't doing any type of validation to ensure
that the user actually wants to change their password.
So the best way to prevent this RF is to make sure that the user is submitting data through a page that
was served to him by the Web application and not by anyone else.
A good way of implementing that is to use synchronizing tokens.
Now, I know the name sounds complicated, but the idea is very simple.
Basically, we want to generate a unique and random token at the server side.
Then when the page is loaded, when the form is loaded, we're going to embed this already generated
token into that page as a hidden form.
Then when the form is submitted, we're going to make sure that the form was submitted with that token
that we sent to that specific user.
So basically we give the user a token and then we wait for him to submit the form with the token that
we gave him.
That way, the token that the hacker gets will only work for him.
So even if he generates a page and send it to the target and the target runs the page, the form will
be submitted.
Well, it will be refused by the server because it did not give that token to that user.
It gave that token to the hacker.
Say, for example, we have this user here and here costs Facebook dot com passwords, BHB, it goes
to the server, the server is going to generate a response for that request.
So it's going to return the HTML page that represents password up in that page.
It's going to include a unique token.
So when the page is loaded at the client site, it's going to already have the form that the user is
looking for, plus a unique token that was generated by the server.
Then when the user submits whatever they want to submit, the server will only accept the form and will
or will only response to what the user is asking if the user returns the same token.
Now, if this isn't implemented properly, it can still be exploited.
So if the token was predictable or if the same token was being used, then the hacker can discover what
the token is embedded in the HTML code and send it to the user.
So the focus needs to have certain characteristics so that it's secure and basically the main things
that you want to keep in mind is that the token needs to be unpredictable and it cannot be reused regardless
of the way you're going to implement this.
These are the two main things that you want to keep in mind, because if it was predictable, then the
hacker will be able to create their own tokens and then embed them in the code and run the attack.
Same if the token can be reused, then the hacker can just use their token or someone else's token to
target their target.
So in order to make the token unpredictable and make it so that it can't be used, then the token needs
to be a large value so that the hacker can't do a brute force attack and discover what the token is.
The token needs to be random so that the hacker will not be able to create their own tokens.
And it needs to be unique for each user because if users get the same token or similar tokens, then
they can pass them around and then the tokens that works for the hacker will work for other people.
So that'll divide the whole point.
You can also increase the security of the token by including other factors and the token generation
algorithm.
So you can include, for example, the date and time, then combine it with a secure random generator
and then encrypt that.
All of this is obviously happening at the server side.
So the hacker will not be able to know what algorithm you're using because the code will be executed
at the server side.
You don't necessarily have to do this.
Using a secure, large and unique random number is enough.
But if you want to increase the security, then you can just add other factors and encrypt the token
before you send it to the user.
This is actually implemented in Mattilda, so let me just show it to you in action.
So I'm just going to go to Mattilda and here.
And I'm going to go on our stand here, SRF and Autoblog.
So this allows you to add a blog post so it doesn't allow you to change your password or anything.
It actually allows anonymous people to add posts as well.
So you can't really ask people for a password.
I'm actually going to go and toggle security so that it's the highest because it's a zero right now.
So now it's the most secure and if you right, click this and go on inspect element.
Now, I'm going to scroll up.
And as you can see, we have the forum here and we have a hidden input with a very long value and this
is the token.
So this has already been generated by the server and the server will refuse any request that we send
to it unless it has this specific token.
And if I use this form and send it to someone else, then again, the requests that they will send will
be refused because they'll get a different token.
This token was generated for me and for me only.
So let me show you if I actually refresh right now.
I'm going to get a different token and again, if I refresh again.
I'll get a different token, and if I modify this, so let's say instead of the capital, I at the end
I'm going to put a small I.
And if I submit this now.
It's given me an error, but let me not change this.
So, again, I got a different token now and if I just submitted the way it is.
It's going to work and now we have a blog entry called Test, so that's it, it's actually very, very
simple.
I didn't want to go into too much details about how to create random token and all that, because that's
going to be specific depending on the programming language.
That's the Web application is programmed in.
But I was I just wanted to show you the concept or the idea of how to secure Web applications against
this type of vulnerability.
The whole idea is you want to make sure that the user submits their data through a page that you served
to them and not by a page that was given to them by any other person.
So in order to do that, we generate a token at the server side.
This token needs to be long, random and unique.
Send that token with the page, with the form and embedded as a hidden form.
And then whenever a user submits the response, make sure that they submit the same token that was given
to them.