Forum Moderators: open
My problem is that a web application server in another part of the domain controlled by another developer which uses JSP sessions to track users after they have logged in. Typically, the establishment of a session object includes the creation of a session cookie which terminates when the browser is closed or the server commands the browser to eliminate it. We have discovered, however, that IF our permanent cookie is created first, the session cookie data will be written INTO the permanent cookie that already exists for the domain. This is a huge problem for us as this application (used by thousands of people) grants access to federally protected personal data. With the session cookie permanently planted, we can actually CLOSE THE BROWSER AND RESET THE COMPUTER, reconnect to the website, and resume the session of the previous user. This behavior remains until the user either clicks "Log Out", initiating code that forcefully deletes the cookie data, or the session hits its 15 minute idle timeout. To make matters worse, we have kiosks set up in public areas to let students (this is a university website) access the school websites and applications from common areas in the student lounge and the library.
Has anyone seen this behavior before? We're running iPlanet6 on Solaris on the application server, and I don't believe that any of the configuration options for sessions have been tweaked. I've never seen this kind of behavior before and am kind of STUMPED about how to proceed. Suggestions?
How are you setting the cookie? JavaScript or server-side? And the session cookie?
Have you tried viewing the 'document.cookie' string at the different stages to see what's happening? Is the JSP code 're-newing' the other cookie? A cookie is just a text string so it can't _do_ anything. The answer must be in the code.
Additionally, an option might be to include a onunload() command on the body of your pages that deletes the cookie and/or to shorten the prescribed life of the cookie. While dcrombie is right, all cookies have an expiration date, it is possible to set it out many years.
the session cookie data will be written INTO the permanent cookie that already exists for the domain
That does not make sense.
Just make sure you use different names for cookies.
bcc1234 makes a good point, using a different name should create a separate cookie and limit access by an app unaware of the cookie name, but a hacker who knew its name could easily figure a way to load the cookie if it exists in the same domain and directory tree. Worse, a spontaneous power down during a session could leave the cookie contents on the disk and as long as the browser was not reloaded, a hacker could get the contents from the temporary files.
Given the sensitivity of the data and the ingenuity of hackers the following should be considered:
1) Place the pages of the two sites in different directory structures to limit access. Control permissions precisely with the domain and path attributes of the cookie. This will help prevent two sessions on the same machine from having cross permissions.
2) Make sure the cookie has a unique name.
3) Give the cookie a very limited life and only write it in preparation for switching pages, when such switches are fully under the app's control (i.e. use JavaScript to handle and control all links). Read the cookie upon loading the new page, store the information in a memory variable, and destroy the cookie. The user's changing URL's outside of the app's control should not trigger a cookie write. This way a spontaneous power-down event will be less likely to leave usable cookie residue on the drive.
4) Encrypt the cookie contents.
Make no mistake, even with these procedures your information will only be minimally secure. A hacker can create a shell in a higher level language that surrounds the browser session and intercepts its input and output. This is how some popup blockers, such as the one in Norton, work. For real security you need to use https: and server side scripts.
The first cookie to be set is planted via Javascript and has an expiration time of 365 days. That cookie is named 'cstyle' and is set to be available domain wide, not just to the current page or directory structure. We had to do this because the website spans multiple physical servers and subdomains, and the cookie needed to be accessible to all pages sitewide.
The second "cookie" is generated server side and is simply named 'JSESSIONID'. The cookies DO have seperate names, but they are being written to a single txt file on the browser. This session cookie should only be available to the browser for the duration of the session, but it is somehow being preserved due to its placement in the same text file as the "permanent" cookie. This is allowing the JSESSIONID cookie to persist despite its immediate expiration date.
I've been writing cookie code for years and have never seen this behavior before, so I'm stumped. Do you think that enabling SSL might help? Immediately terminating all cookies, clearing cookies between page transitions, or seperating cookies by the part of the site will all result in a loss of functionality, so I'm really not wanting to go down that road if at all possible (not to mention the fact that it would require modifying thousands of webpages already ported to the new layout).
I'd suggest only writing usable data to the cookie in preparation for switching pages, read the data into a memory variable on the new page, then zero out the cookie by writing a nonsense string, or better yet, a string insulting the genetic heritage of criminal hackers.
