cookie problem

Viewing 5 reply threads
  • Author
    • #2990

      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?

    • #20481

      From your post I am assuming that you are creating a Web application. I will also assume that when you talk about “RAM cookies” you are referring to session cookies. While session cookies will be destroyed when the browser closes, they are sent to a Web server in the exact same manner that any other cookie is sent, so there is no way for you to determine if a cookie has been saved to disk or not.

      If you are concerned about the security of your session cookies, keep these points in mind:

      • Session cookies are usually captured by an attacker via packet sniffing or XSS attacks. Using SSL and sanitizing user input to prevent XSS will go a long way in ensuring the security of your cookies.
      • Cookies can also be marked as http-only, which prevents JavaScript code from accessing them.
      • I don’t know what language you are writing your application in, but most languages have built in support for session cookies, and will automatically time out the session cookies after a pre-defined period. This way, even if a session cookie is compromised, it will only be useful for a finite period of time.
      • If you are concerned about preventing client impersonation, also ensure that you protect your application against CSRF attacks.

      Hope this helps.

    • #20482

      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!

    • #20483

      Ok thats fine.But still have a problem.Take the scenario in this way.

      I have an application in which the session cookies are stored.The application is commercial application and login is allowed only over a single machine.But i have cookies built for my application in such a way that a person in the same network can use the cookies and login over another machine.Now if i insert the logic of ip address in my cookie , means if i start accessing the ip from which the request was made, i cannot do so as ISPs and the client machine ip may change dynamically very frequently.So i need to know if i could insert any logic to build my cookies so that i have such information of the client that he cannot be impersonated by anybody else or the same login could be used on some another machine.Hope i have been able to explain the problem.

    • #20484

      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!

    • #20485

      Thanx a lot 4 the response.One more scenario i have 4 which i need solution.It goes as below:

      I have a login page of my application.The action associated with the login page is to call authentication check script which checks the username and password from my database and if valid allows login.Now If someone builds the same page on some other domain and specifies the action of that page as my application script being called on my server.This will allow him to access the username and paswords and then redirect to actual page on my server which is shown when the login is correct.Can i check if the login request is being made from my domain or some other.I have the option of seeing referrer but believe the same can be blocked/played with to launch the attack.I need a solution so that the same can be stopped.Please help.

Viewing 5 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2020 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?