Page 1 of 1

$_SESSION hijacking

Posted: Sun May 17, 2009 7:43 am
by JustAnotherCoder
Hi everyone,

I have been on this forum a couple good times. But this is my first time posting. Sorry, I just wanted to introduce myself haha jk.

My question concerns $_SESSION hijacking. I have been developing a web application and have been implementing security to prevent from your day to day XSS and SQL injection.

When I login into my private areas of the application I used 'echo session_id()' to display the SessionID in my firefox browser, I then copied the session_id and opened up safari... and pretty much did this in the url http://www.example.com/user_account.php ... ID=1234567 <-this being an example of the session_id I obtained previously.

With this being successful I was able to play around, delete and modify certain things such as files and information.

My real question is how does one actually Hijack sessions? What are some common ways that you may know of? I know some of the basics such as visiting someones website by clicking on a link that will automatically set the victim with a defined session_id for the attacker to use later.

If you have information on hijacking session_ids via http headers etc I would really like and appreciate the information and solutions that you may have.

I'm sorry if this message is hard to follow, I been up for a long time. I appreciate your time and your help... thank you in advance!

- Cypherpunk

Re: $_SESSION hijacking

Posted: Sun May 17, 2009 8:27 am
by Darhazer
First, to prevent the presetting of the session id (known as session fixation attack), when you are login (or change privileges in any way) - regenerate session id. This means that if I give you a link with a predefined session id, you are clicking, it requires login, because the session does not exist... after the login, that session id that I gave you will still require login :)

Second, most common way to hijack a session, is a XSS attack, so I just give you a link and (if XSS is present) your cookie is sent to my server. I think you know enough of XSS :)

Lastly, you can lock your session id to an IP... so you can verify that it was not stolen. Using the same computer for tests, you will still be able to steal your id, unless you don't lock to the user agent as well.

Re: $_SESSION hijacking

Posted: Sun May 17, 2009 8:51 am
by kaisellgren
Session Hijacking is when another person gains an access to the system without "loggin in". He uses the already created session to gain the access.

As you noticed, if another person gets your identifier, he can use it to get an access to your system. There are a few ways someone might get into your session and in each scenario the attacker knows the identifier. Regenerating the identifier prior to successful logins prevents Session Fixation attacks, stronger session identifiers prevent guessing and some sort of login limiter prevents brute forcing attacks. Setting the cookie session identifier as secure ensures that the session identifier cannot be stolen in HTTP-mode by XSS attacks and the use of HTTPS will make sure an eavesdropper or a MITM cannot sniff your session identifiers and in fact, ultimately you must use SSL/TLS to prevent session hijacking.

Re: $_SESSION hijacking

Posted: Sun May 17, 2009 9:00 am
by JustAnotherCoder
Excellent!

Thanks for your replies.... Yes, I think I may have been paranoid... But its good to see some of the solutions you mentioned already applied in my program.

The SSL is something I wanted to throw in. I want to use OpenSSL have any of you had any experience with it? Are you pleased with OpenSSL? Experience any flaws?

Again thanks everyone for your comments... it is always better safe than sorry.
I really appreciated it.
-Cypherpunk

Re: $_SESSION hijacking

Posted: Sun May 17, 2009 9:14 am
by kaisellgren
JustAnotherCoder wrote:I want to use OpenSSL
Use it for what? To create certificates? Sure why not. If you want to sign the certificate and use it in a public website, then the one who signs it must be trusted (e.g. VeriSign).

Re: $_SESSION hijacking

Posted: Sun May 17, 2009 9:38 am
by JustAnotherCoder
kaisellgren wrote:
JustAnotherCoder wrote:I want to use OpenSSL
Use it for what? To create certificates? Sure why not. If you want to sign the certificate and use it in a public website, then the one who signs it must be trusted (e.g. VeriSign).
No, I want to use OpenSSL to encrypt data that will be transferred over the network. I can sign my own certificate or have it done by a globally recognized certificate authority.

You must obtain a certificate signed by a recognized Certificate Authority in order to establish a commercial site, e.g., for conducting "e-commerce".

Considering its not an e-commerce site or anything like that I thought I might try it.

Re: $_SESSION hijacking

Posted: Sun May 17, 2009 9:50 am
by kaisellgren
JustAnotherCoder wrote:You must obtain a certificate signed by a recognized Certificate Authority in order to establish a commercial site, e.g., for conducting "e-commerce".
Not just e-commerce, but websites in general. If you just sign it on your own, then web browsers will throw ugly warnings at your visitors and many of them will leave your site.
JustAnotherCoder wrote:Considering its not an e-commerce site or anything like that I thought I might try it.
You can always try, it's free. I use OpenSSL on my developer machine and I access my scripts through the HTTPS -protocol.

Re: $_SESSION hijacking

Posted: Tue May 19, 2009 3:14 pm
by Mordred
kaisellgren wrote:Setting the cookie session identifier as secure ensures that the session identifier cannot be stolen in HTTP-mode by XSS attacks and the use of HTTPS will make sure an eavesdropper or a MITM cannot sniff your session identifiers and in fact, ultimately you must use SSL/TLS to prevent session hijacking.
I'm sorry, are you still writing that book of yours? You might want to let your readers know that HTTPS does not, in any way, prevent XSS, and that cookie stealing still works, barring a notice or two (depending on the browser and configuration) that noone would really read.

Re: $_SESSION hijacking

Posted: Tue May 19, 2009 5:03 pm
by kaisellgren
Mordred wrote:You might want to let your readers know that HTTPS does not, in any way, prevent XSS,
Is there a reason for them to believe so? HTTPS and XSS are two different subjects.
Mordred wrote:and that cookie stealing still works
Maybe or maybe not. Some browsers (standard browsers) do not give out their cookies when utilizing HTTP in case the cookies were created for HTTPS-mode. It's not the HTTPS itself, it is the behavior of the browser that does the "trick".

Re: $_SESSION hijacking

Posted: Wed May 20, 2009 4:31 pm
by Darhazer
Actually the 6th parameter of setcookie() is the one that says that the cookie should be used over https only. The 7th is that cookie should not be used by JavaScript anyway, but this is relatively new parameter and I don't know what's the browser support for it.

Re: $_SESSION hijacking

Posted: Wed May 20, 2009 4:45 pm
by kaisellgren
Darhazer wrote:Actually the 6th parameter of setcookie() is the one that says that the cookie should be used over https only. The 7th is that cookie should not be used by JavaScript anyway, but this is relatively new parameter and I don't know what's the browser support for it.
What I said earlier was about the secure flag that you can set for a cookie. If you do so and you load a web page in HTTP - you cannot steal the cookie with XSS, because the web browser never submits the cookie since the cookie is sent only in HTTPS. Neither the site or an attacker can get this cookie unless the web browser do not obey the rule, which rarely is the case nowadays.

The new parameter (HTTP-Only) does not prevent XSS cookie stealing entirely. It is implemented in mainstream browsers, but IE6, IE7, earlier Fx 3 releases and some other browsers do not support it. The only way to steal a cookie with that feature taken into account is to be able to access the HTTP headers.

Re: $_SESSION hijacking

Posted: Fri May 22, 2009 3:15 am
by Mordred
@JustAnotherCoder:
The point of security in SSLs is that they are signed by a trusted party. Using a self-signed certificate is good for testing, but it doesn't solve the problem SSL is meant to solve: a MITM can still replace your server with his own, using his own self-signed certificate which will be as good as yours from the point of view of the client. The client will see a warning saying that "this certificate is not signed by a trusted authority blablabla" in both cases.

@Kai: I already quoted what you said, I don't have to repeat it, just scroll up ;P

Re: $_SESSION hijacking

Posted: Fri May 22, 2009 6:20 am
by kaisellgren
Mordred wrote:@JustAnotherCoder:
The point of security in SSLs is that they are signed by a trusted party. Using a self-signed certificate is good for testing, but it doesn't solve the problem SSL is meant to solve: a MITM can still replace your server with his own, using his own self-signed certificate which will be as good as yours from the point of view of the client. The client will see a warning saying that "this certificate is not signed by a trusted authority blablabla" in both cases.
That's correct. In addition, in some cases all you want is to encrypt the connection - not to identify anyone (it is either not needed or done in some separate process).
Mordred wrote:@Kai: I already quoted what you said, I don't have to repeat it, just scroll up ;P
Okay, let me see.. I said:
kaisellgren wrote:Setting the cookie session identifier as secure ensures that the session identifier cannot be stolen in HTTP-mode by XSS attacks
You responded:
Mordred wrote:You might want to let your readers know that HTTPS does not, in any way, prevent XSS, and that cookie stealing still works, barring a notice or two (depending on the browser and configuration) that noone would really read.
1) I never said that HTTPS prevents XSS - can you even see the word HTTPS in my sentence? No? The only word you can see is the cookie secure flag, which refers to a cookie parameter and not to HTTPS.
2) Cookie stealing might work = the browser does not support secure-flagged cookies properly or it is running in HTTPS-mode (which I took into account in my post). Of course, even HTTPS does not prevent MITMs or eavesdroppers if the browser lacks of HTTPS support :). And yes, the secure flag is supported by the major web browsers, because it was invented many years ago.

Maybe I should have said "cannot be stolen in HTTP-mode by XSS attacks in general".

And the rest of the sentence had nothing to do with XSS:
kaisellgren wrote:the use of HTTPS will make sure an eavesdropper or a MITM cannot sniff your session identifiers and in fact, ultimately you must use SSL/TLS to prevent session hijacking.