wood burning stoves 2.0*
The moose likes Servlets and the fly likes Session Invalidate Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Session Invalidate" Watch "Session Invalidate" New topic
Author

Session Invalidate

Pawan Komaram
Ranch Hand

Joined: Dec 08, 2009
Posts: 91
How Can I invalidate a session if user tries to perform incorrect operation? something like direct access to secure URLs, tries to open a secure page from a different mahcine by hijacking the logged in user's session id? Overall, I want to prevent Man-in-the-browser attacks. Eventhough SSL is implemented to prevent the capturing sensitive data over the network, still there is a possbility that sensitive data can be captured within end-user's PC through some spam or Man-in-the-browser kind of attacks and use this data to access secure pages of that user. I just wanted to identify this kind of requests and immediately invlaidate that particular session.....How to achinve this?

We see this kind of session expired messages, when we are using prominent banking or financial websites. They even make session invalidate if user ckicks on back or forward or refresh buttons... How are they achieving it?
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12761
    
    5
Detecting bad behavior is up to you but javax.servlet.http.HttpSession has the invalidate method.

Bill
Pawan Komaram
Ranch Hand

Joined: Dec 08, 2009
Posts: 91
I can call the invalidate method, if I know that request is not coming from real user (who really logged in), here my question is how to identify whether a request is coming from logged in user or some unknown user who hijacked the session id? How to differentiate this kind of requests, so that I can call invalidate method.
Kumar Raja
Ranch Hand

Joined: Mar 18, 2010
Posts: 518
    
    2

Your issue is more of a session fixation rather than Man in the Middle, as I believe use of SSL prevents Man In the Middle attack. So for session fixation and session hijacking, you may want to go through the link

https://www.owasp.org/index.php/Session_Fixation_in_Java..


Please share your results back.


Regards
KumarRaja

Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60800
    
  65

If you're not using SSL, you might as well take out a billboard to advertise the users' passwords.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Pawan Komaram
Ranch Hand

Joined: Dec 08, 2009
Posts: 91
My application has got SSL implementation, hence there wont be session id hijacking over the network, but a session id can be hijacked from and within the user's PC (where user logged in), something like Man-in-the-Browser attack by just sending some spam or using some other technique. Lets's say by someway session id is hijacked then how can we prevent this kind of requests?
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3817

Kumar Raja wrote:... you may want to go through the link

https://www.owasp.org/index.php/Session_Fixation_in_Java..

That link doesn't seem to have any content in it. Or is it require a log in?


SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Nauman Hasan
Ranch Hand

Joined: Jul 27, 2005
Posts: 34
Try this link instead:

Session Fixation

You should look in the related attacks section as well for the XSS and the links to the Session Hijacking areas which are related.

~Nauman
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3817

Thanks for fixing the URL...
Kumar Raja
Ranch Hand

Joined: Mar 18, 2010
Posts: 518
    
    2

My bad, for providing invalid url.

Thanks Nauman, for fixing it.
Pawan Komaram
Ranch Hand

Joined: Dec 08, 2009
Posts: 91
Still my question is not answered. I am talking something like Man-in-the-Browser attack by just sending some spam or using some other technique. If the session Id is hijacked by any of the mechanism (by social engineering etc), is there a way to identify the attacker and ivalidate session.

Here the point is not how to prevent the session id hijacking but after hijack has happend, how can we identify that a request is not coming from the real user.
Kumar Raja
Ranch Hand

Joined: Mar 18, 2010
Posts: 518
    
    2

Pawan,

Let us think this way, if any abuser hijacks the session successfully and replays it back, how would the server differentiate that request with a legitimate one, when all it knows the sessionid. In what other way, it could recognize the user. So, as you said, if any one is succeeded in session hijacking and plays it back, I think there is nothing much you can do. So the key is how to avoid it.
Ankit Nagpal
Ranch Hand

Joined: Sep 09, 2008
Posts: 47

Pawan Komaram wrote:Still my question is not answered. I am talking something like Man-in-the-Browser attack by just sending some spam or using some other technique. If the session Id is hijacked by any of the mechanism (by social engineering etc), is there a way to identify the attacker and ivalidate session.

Here the point is not how to prevent the session id hijacking but after hijack has happend, how can we identify that a request is not coming from the real user.


You could have a look at how to prevent your JSESSIONID cookie from being read/modified at the client side to stop the hacking. Making this cookie HttpOnly would prevent the read/modify operations and also follows a simple rule: Prevention is better than cure.

Ankit
Pawan Komaram
Ranch Hand

Joined: Dec 08, 2009
Posts: 91
Again my question is not understood correctly, lets say a user who has logged into an application intentionally looked into the browser's cookie area and takes the JSESSIONID from it and shares it with some one who can access his account from a different machine by using this session id in the url as parameter or setting it as a cookie in his browser. I want to prevent this kind of requests....
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60800
    
  65

Is this a realistic enough scenario for you to be spending time on it?
Pawan Komaram
Ranch Hand

Joined: Dec 08, 2009
Posts: 91
Yes it is. My security audit team is trying to trouble me with this issue, and I wanted to prove them wrong. After a week long discussion with them I agreed with them that this kind of attack (Man-in-the-Browser) is poosible in worst case scenario. So now, I must fix it. Do you know, some banking websites do show the Session expired page whenever a user clicks on refresh or back buttons or double clicks on any button or even when we copy currently opened secure URL to a new tab or new window. How are they achieving it?
Kumaravadivel Subramani
Ranch Hand

Joined: Jul 05, 2008
Posts: 166

Banking web sites all are "https" used protocol and it would require authentication to display a page even though, you copied a URL from a current page which is logged in. To identify duplicate request by refresh it's up to your logic to stop it. Can use request token stored in session checks for duplicate request, form unique validation before submit etc.


No pain, No gain.
OCJP 1.6
Pawan Komaram
Ranch Hand

Joined: Dec 08, 2009
Posts: 91
Even my site has got https SSL certificate.........I dont think they do authentication every time.. as long as the session is identified by using session id then the server proceed with serving secure page......And whatever request tokens that have been placed in session will also be the same for real user and hijacker who also passes the same session id.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Session Invalidate
 
Similar Threads
Session handling
How to prevent cross site cripting parameter manipulation attacks in jsp?
Struts 2 and Authentication Interceptor - is this secure?
Session
Restrict Login from Multiple Sessions