Session Hijacking

[vjy chin]

I have a question about session hijacking. Is it easy to hijack or hack a session. If so can we encrypt the session and send it.
e.g. I am sending the users info from a jsp page to a servlet. Instead of using request.getParameter for all the values, I want to set the values in an object and send the object to the servlet. Some people say to use sessions for this. But some people told its not advisable.

If its so easy to hijack this, then why in the first place do we have them. If we encrypt the session and decrypt the session in the servlet will it be useful. If not how the ssl and other encryption mechanism work. How the credit card nos are being processed by Verisign and other CA's.

Any ideas and suggestions would be great. Also please if you can point me to more readings, it would be nice.

Thanks

[Sharad Agarwal]

Originally posted by vjy chin:
e.g. I am sending the users info from a jsp page to a servlet. Instead of using request.getParameter for all the values, I want to set the values in an object and send the object to the servlet. Some people say to use sessions for this. But some people told its not advisable.

If its so easy to hijack this, then why in the first place do we have them. If we encrypt the session and decrypt the session in the servlet will it be useful.

This part seems to indicate that you are talking of a request forwarding within the application in the server side. There should be no issue of session hijacking here.

Originally posted by vjy chin:

If not how the ssl and other encryption mechanism work. How the credit card nos are being processed by Verisign and other CA's.

Any ideas and suggestions would be great. Also please if you can point me to more readings, it would be nice.

Thanks

This section refers to the client-server interaction and the big, bad internet in between. That is an interesting question. This is handled via SSL. Lets say the client is C and the server is S. When C sends a message to S, it uses the public key of S. That way only S can decrypt the message. In the first handshake, C alse sends an encryption key to S (the key itself encrypted). S uses the key it received from C when it sends a message to C, and only C can decrypt it. Lookup public key cryptosystems to understand this better.

So, if SSL is used, the cookie information (and most of the information in the exchanged packets) is only available in garbled format to the internet. The only information that is in clear text is the routing information.

This does, though, leave the possibility of man in the middle attacks. That is where, I believe, certification authorities step into the picture. The server needs to send its certificate, which the browser verifies against a CA.

[vjy chin]

Thanks for the nice reply dude.

Actually I am submitting the results from the jsp page to the servlet and not forwarding to the servlet. To my understading they two are different, is it not? If not I apologize for the mistake.
If I need to forward the page I can use request.setAttribute to set the object and get the object in servlet using request.getAttribute.

But I want to submit the page. This is why the sessions came into picture. So do you mean to say that even when we are submitting the page, session hijacking will not be a problem?

I do know a little about the cryptography. So I feel that the middle man attacks are possible, but as you said CA's would be helpful in dealing with this. But still consider this scenario,

after initial process, Server will send its certificate to the client, so the client accepts and again sends the query, but is it not possible for the middle man to attack the data now, or is it not possible since the SSL communication has already been established. Please let me know if I am wrong.

Also it would be great if anyone could tell me how other sites are doing these things. How other sites handle the credit card processing.

Thanks for all the help.

[Sharad Agarwal]

Originally posted by vjy chin:
Actually I am submitting the results from the jsp page to the servlet and not forwarding to the servlet. To my understading they two are different, is it not? If not I apologize for the mistake.

Initially I thought it was an internal forward. The two are different and I understand your issue now.

Originally posted by vjy chin:
But I want to submit the page. This is why the sessions came into picture. So do you mean to say that even when we are submitting the page, session hijacking will not be a problem?

Yes, that is correct. If SSL is used, session hijacking should not be an issue.

Originally posted by vjy chin:
Please let me know if I am wrong.

Right again.

[Ben Souther]

A session is nothing more than a map of references to objects living in memory on the server. It's not something that is shipped from the server to the client and back. The only thing "session related" that travels across the internet is the JSESSIONID header.

If someone got a sessionID and had all of the other needed form information there is a chance that they could start using the app as a logged in user.

As mentioned before SSL takes steps to avoid this type of spoof.

If you're still paranoid, keep the origninal IP (from the login) in session and compare it with each request to make sure its the same.

[S Herod]

Checking the 'from ip' is likely to cause issues if the user is coming through a proxy server which load balances as the users from IP address may change between requests.

So I wouldn't do it that way.

On another note

PHP has/had a flaw (apparently) in that its session id's were predictable, so if you visited the site and got a session id, you could use that to predict a future session id and thus hijack another users session.

I don't know if JSP/Java suffers from such a problem, I suppose it has to do with the implmentation by the servlet container (??)

[vjy chin]

Thanks for the reply.

Originally posted by Ben:
A session is nothing more than a map of references to objects living in memory on the server. It's not something that is shipped from the server to the client and back. The only thing "session related" that travels across the internet is the JSESSIONID header.

If that is the case, how will the values travel first time? Is it that only for the first time the value will travel to the server, then after that only the session id will be transferred. If so what will happen if the session is updated?

Also is it ok to just encrypt the session key, or should I try to encrypt the whole session. If so what is the procedure, since I searched through google, couldnt find much help there. It will be great if anyone can enlighten me on this issue on how to encrypt the session.

I think to encrypt the session key, i need to get the key from session and encrypt it using encryption algorithms. But for session how can I do it?

I will still look into more tutorials, but any help in this would be greatly appreciated.

Thanks

[Ben Souther]

If you encrypt the sessionID the either the server or the browser won't be able to read it.

Let SSL handle all of the encryption/decryption for you.
When you switch from insecure to secure the container changes the sessionID so someone sniffing your session can't use the original sessionId to gain access to your session.

The values in session start, end, and stay on the server. If you want to send them back and forth from the browser, you need to send them as HTTP form parameters (which SSL will encrypt for you).

[Sharad Agarwal]

Originally posted by vjy chin:

Also is it ok to just encrypt the session key, or should I try to encrypt the whole session. If so what is the procedure, since I searched through google, couldnt find much help there. It will be great if anyone can enlighten me on this issue on how to encrypt the session.

I think to encrypt the session key, i need to get the key from session and encrypt it using encryption algorithms. But for session how can I do it?

Please see Ben Souther's response. I think this confusion has been created a bit due to my explanation of how SSL works. As an application developer, you need not involve yourself in the encryption/decryption at all. You only need to configure your application server to use SSL for your application. Once configured, all the process I described (public/private keys, encryption, handshake, etc) will be handled by your application server and the browser auto-magically. You can rest assured that your application is pretty solidly secured as far as session hijacking is concerned.

You might want to take some time to readup on the session object and session management from a good book. Feel free to ask more questions here as well.

[vjy chin]

Thanks for the reply.

So you mean to say that if I use https instead of http, it would be sufficient. Is it so?

Thanks once again for the help guys

[Sharad Agarwal]

Originally posted by vjy chin:
So you mean to say that if I use https instead of http, it would be sufficient. Is it so?

Yes!