Hi all

Have a problem to discuss.I have ram cookies enabled instead of hard disk cookies for my application.Now while auditing my application, i opened the login page on a machine and login inside with the required credentials.Then on the other machine i copied the ram cookies from the browser into the browser running on other machine say machine2. The i fetched the url from the previous machine (which was the url which i got after logging in) and ran it on the machine2 browser.I got logged in.Believe though i used the ram cookies and copied it,but still need some way or idea to implement in my application so that even if someone could have my ram cookies for the running session, he should not be able to login.

What logic/intelligence should i insert in my application?

I agree with Craig, but on top of the things that Craig mentioned, the answer partially depends on what you are trying to protect.  If you were a banking institution then the answer would be different than an online forum. 

Unfortunately due to proxy use in some of the larger ISP's, the IP address is a bad thing to use for security.  There will be some users who will get denied just becase of their ISP.

The security is to have your sessions themselves timeout after a short period of time if you can.  That is why if you go and get a cup of coffee while you are on a bank site you will find yourself logged out.  Unfortunately allowing short session times doesn't work with everything.  For instance, it isn't much fun when your session times out while you are trying to make a post on a forum.  So you have to balance the two.  For a bank, maybe 10 minute session timeouts.  For forums, maybe 2 hour timeouts.

You can also tie some client information to the session if it is important that the information remain safe.  This won't stop people who are very creative, but does raise the bar some, and for automated attacks may cause fewer problems.  For instance, keep the user agent in the server stores session, if the user agent changes, log the person out. Browsers are also pretty noisy in many occasions as to what they will tell you when they make a request.  Adding in something random like the Accept-Charset field which is accessible from most applications may make it secure enough to deter someone who isn't overly intent on messing with you.

Overall, the best way to prevent session theft is to make sure that your website is properly coded and you have input validation issues handled.  Making sure you have good input validation will go a long way to preventing XSS, SQL Injection and a few other types of attacks.  Check out the OWASP top 10 for common ways to prevent application problems. 

Hope this helps!

I understand what you're saying, but I'm afraid your logic is flawed; you want to be able to send some un-encrypted token (i.e., the cookie) across an un-secured network, and have that token tied to only your IP address, even though the Web server has no way of knowing for sure what your IP address is. I think the better solution is to simply encrypt the traffic to prevent cookie theft in the first place. However, if you really want to tie it to some dynamic IP address, you could set up a dynamic DNS solution where your computer, no matter where it is or what IP address it has, updates a specific DNS entry whenever its IP address changes. When your web application sees a request come in, it can lookup the DNS entry and see if the IP that the entry resolves to is the same IP that made the request. Of course, you have to ensure that whatever dynamic DNS solution you choose is secure, because otherwise someone could sniff your credentials for that and update your DNS host name with their own IP address (starting to get into the chicken-and-egg problem here). Remember also that this will not protect you against XSS and CSRF attacks.

I think that the best solution to your problem is to follow the guidelines that apollo and myself have already laid out: protect your application against XSS and CSRF, prevent JavaScript from accessing your cookies, and encrypt your traffic. This will help keep third parties from getting your cookie in the first place. Of course, you could also set up an SSH tunnel to your Web server that then connects back to itself on port 80 of the loop back interface - it would probably be slow, but really secure!