So some Web application servers set an anonymous session ID cookie prior to login.
And session fixation vulnerabilities typically arise when an application does not renew this anonymous
session and after a successful login.
So this means the anonymous session indeed is upgraded to an authenticated session and.
I don't know about you, but it occurs to me that this is a very bad implementation of development and
server configuration.
However, the worst is that some Web applications and servers accept arbitrary session IDs submitted
by users, even if these were not previously issued by the server itself.
I don't know, is it just me or does that seem like a problem?
So when an unrecognized token is received, the service simply creates a new session for it and handles
it exactly as if it were a new token generated by the server.
So we enforce the victim to use this anonymous session identifier, then we can accomplish a session
fixation attack.
So open up COWEY, and log in to be Web.
Then open session ID in your URL under this session management section.
And as soon as you open the page, you will see the session and value of yourself in the early.
Sometimes applications can use a session in value this way for whatever reason.
I don't think it's a good way and we're going to see why.
So the first reason is the heightened value will be saved in log files.
OK, so go to B box and view the Apache access file.
And scroll down to see the latest request.
And this is what happens.
Session and drivers in the euro, but as I say, the worst is if you're able to force the application
to create a session with an arbitrary value.
OK, so go back to Kawi and be there's no option for a session fixation.
So you can import the sample application from this, your URL to use it.
Imported into the web, rude of B box and use it there.
So now what we're going to do is, OK, so first I'm going to get a session ID prior to log in, so
go to SRF home dot p.
This page needs authentication, so it will send you to as log in to BHP.
And this is the login page now below, you'll see the session ID defined by the server.
So just for ease of use, I'll just print it to page.
And the login form has default values and again, for ease of use, you can see here from the source
better, I think.
Then I will carry this you URL that contains a login page.
Or you can actually use any page that needs authentication.
And pasted here.
Then copy the session value.
After the question mark, questionmark it here as well.
So until now is a hacker or a pen tester, I created a new URL that contains a session value, right?
And now I need to send this URL to the victim somehow.
So this may be, I don't know, a phishing e-mail or whatever you may think of.
But for now, I'm just going to copy and open it in another browser to show you, so go to Firefox and
paste the URL.
Now, before sending enable Foxe proxy.
And activate burp and interception mode.
All right, so now I'm going to divide my screen so that you can see Berp and Firefox's and send.
And what you're seeing here is we're defining a session indeed from the euro, so forward it.
And here's the login page.
But with a session that we provided.
All right, so forward it.
Now the victim opens the link we sent.
Then the user will log in and I'm logging in as the other user admin.
One, two, three, four, five and log in.
Burp, intercepts of request.
And as you can see, it did indeed use this session that we provided the login information is true.
So the victim is redirected to the home page.
And then finally, the home page is open for the victim, so.
What are you going to do is a pen testor?
Just go to Chrom and refresh the page or go to home, because the session is authenticated now.
You see, we share the victim session.
So accepting the sessions in your cell has got to be reported.