Everyone welcome back to the last section of this course as
we have seen various attack scenarios in both Urban Network as
to how an attacker can hijack session. Now,
let's try to understand. How do you secure them?
I will start out by saying that such an it should be
treated as passwords. The reason being that the
way we treat complexity of the password to
ensure that they are not
following any dictionary patterns or it
is not something that is guessable by
any attacker that way. You have to ensure that
decision IDs that are generated are
quite random.
So if you remember particular example that we
look in the Hands-On section where our
session IDs at a typical pattern in the form of
dates. So, given
a certain amount of time, an attacker can
actually reduce what is a pattern in
a small window by doing. So, what's
going to happen now is that the attacker can generate new
session IDs?
Now paste on the vulnerability that our website might
process. We be a session fixation attack
or a Brute Force attack. Any
of those scenarios can actually give an attacker certain
amount of time to actually send
those new IDs to the server and
to check if those sessions are
actually valid or not. There should be no reason
for the developers who generate the
session ID themself or to create a
Curtain of the room, all of the common Frameworks
that exist in the market. We p.net PHP
or any search primary languages. Those
Frameworks to handle such an ID is quite well
by that. I do means saying that
they do generate a random session ID.
Unlike the wonderful website that we saw in the demo, where
it was only numbers. And along with the pattern.
These Frameworks will actually help
generate a random number using both alphabets
and numbers. The
same time. They also give an high entropy in
terms of the size by doing. So,
what's gonna happen now is that those
random generated long strings, quite
hard to Brute Force.
Reason being just to remember this important
fact that session ID is actually valuable
elements valid, you ought
to Brute Force. Our large string, with all of these possibilities is
going to take quite a long time. And
by that time, we should have additional measures
to expire the session.
And even though a user session
IDs actually being guests after sudden
were of time, but attacker can
no longer use it.
Sort of attack that we actually looked was where the session ID
was being passed in the URL. Now,
what will happen in two scenarios. We
really don't want any attacker sitting in an open Cafe
to sniff bar. You are, or
there are scenarios where end users actually share
any existing URL to
the friends or colleagues or social media?
Unknowingly such an ID being
present in the URL. Now, becomes a very big threat
because we don't know if an attacker is actually a
waiting for all of these social
media guys, post any search warrants.
Second problem would be since all
these websites communicate with each other. So
these session IDs sent as
part of the referee header. Also, get logged
at multiple destinations way
our app. So we'll also behave is that any
user accessing the URL gets
logged into the access law.
So given a scenario where the server itself
is compromised and all the URLs
are being locked in the access logs. That occur are
no longer needs to wait for a while and website or
any social easily tactics. He
can just go ahead and access the log and
get fresh new available session
IDs.
So one of the common scenario that you have seen is because there
are rappers, they use HTTP cat
method. The problem with that method is that all
the parameters will always be sent as part of the URL.
So, one simple way to medicate them
would always be to use post method, post
method ensure that the
request is being sent as part of the body.
And a much, much better approach would always be
to use cookies. So as we saw
in our initial videos, cooking
is a file which actually get stored on
the browser. Now, there is no need for
any vulnerability, we present
in the URL.
104 common attack went to that. We
saw was specialization where a particular
session ID was generated and
being given to the victim.
And that particular session ID was fixed
as part of the vulnerability.
So, there lies the actual issue where the
server was not actually regenerating a session ID.
If the developer was smart enough to ensure that once
a person is trying to reopen ticket or
a session ID is actually expired. Then
we ensure that a new random session
ID is generated. So that itself will
actually fixed a lot of session fixation
attacks.
That's it for this video. Thank you.