Link to home
Start Free TrialLog in
Avatar of sb1977
sb1977

asked on

JSESSIONID cookie exposed to non-secure pages after being set in a secure page

Requests to my application are handled in two ways:  1.  Requests to static pages (i.e. .html, .jpg, etc) are processed by an iPlanet server using the non-secure http protocol.  2.  Requests to dynamic pages (i.e. .do, .jsp, etc.) are processed by a Weblogic server using the secure https protocol.  Dynamic pages require a session to be established with clients using the JSESSIONID cookie.  The problem is after a user accesses a dynamic page and the session id is set on the client computer, he/she then tries to access a static page which exposes the session id.

I have attempted a fix where a filter on the iPlanet server expires the JSESSIONID cookie when a static pages is accessed, but this solution only works with Internet Explorer.

Please help!
Avatar of bloodredsun
bloodredsun
Flag of Australia image

>>he/she then tries to access a static page which exposes the session id.

So what? Why are you concerned about this?

The session id is only a number/alphanumeric. It does not contain any data. The session id is only a key that references the session object on the server, nothing is rendered insecure because of this.

If you want to get rid of it, then use url-rewriting rather than a cookie to track the session and then redirect to a no-secure page so that the session id is lost from the URL.
Avatar of sb1977
sb1977

ASKER

I'm just worried that an attacker could obtain the session id and access secure pages that contain sensitive information.  Is this a possibility?

As for url-rewriting, we have decided against this for other security reasons.
ASKER CERTIFIED SOLUTION
Avatar of bloodredsun
bloodredsun
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
hi,sb1977,
               
         Actually you should need to be worried about it so much because url-rewriting has almost same security implication as cookie. It is because if hacker wants to do it, he always can get cookie information from http request as he does for url rewriting. So if you are worried about url rewriting, you should've concerned about cookie already.
         The standard way to secure the url rewriting or cookie is to use https to secure your web application. https is very secure and will protect you from hacking.

Acton        
         
>> Actually you should need to be worried about
                ...you shouldn't ...

Typo,sorry:)
Avatar of sb1977

ASKER

Thank you both for your comments.  Unfortunately, we have a requirement of using both secure and non-secure pages.  I like the idea of tracking the user's IP, but I'm worried if a hacker can get the session id, may be able to do IP spoofing?  Also, do you know if there's some kind of parameter that tells the browser only to send a cookie for secure sites?
Let's put it this way, hacker can do a lot of things even IP fake. So you need to protect all sensitive pages under https and ONLY put some plain pages under http.

Otherwise, you need to use some firewall or such infront of your web apps. which is not neccessary if you use https and http well.
>>hacker can do a lot of things even IP fake

Eh? If you spoof the request IP address of an HTTP request, it means that the response is sent to that IP so the hacker would not get sent the response (the original valid user would). Faking the IP address is common in Spam emails where originating IP does not matter as the email is not going to be sent back but it is not used in HTTP hacking. It's a fairly standard way of further securing the site.

You should always have a firewall infront of the servers to prevent unsecured access irrespective of whether it's secure or non-secure pages you are serving. The asker has alrady stated that they are using HTTPS for sensitive pages so that is a given. Better yet, you should have your weblogic server on another physical server in a DMZ which is only accessible from your company network/VPN or the iPlanet server.

>>Also, do you know if there's some kind of parameter that tells the browser only to send a cookie for secure sites?

Nope, but you can invalidate the cookie once it is no longer used or invalidate the session when the user requests a non-secure page using a servlet filter.
Personally, as long as you follow bloodredsun's suggestions (IP logging, etc), then I'd be more worried about blokes with baseball bats turning up at the datacenter and making off with your servers...
basically, what you need to is just put all your sensitive pages under https, not necessary to use ip logging anyway. The reasons above.
Avatar of sb1977

ASKER

Unfortunately, the boss doesn't think logging the IP is enough and I can't use https throughout the entire site.  I did, however, find a method in javax.servlet.http.Cookie called setSecure() that makes the header parameter look like this:

Set-Cookie: isSecure=true; secure

The "secure" on the end is supposed to force the browser to send the cookie only over secure sites.  After some testing, it seemed to work with a cookie I created, but not with the JSESSIONID.

Any ideas?
cookie for session is set by app server. The name might not be JESSESIONID.
Can I ask what reason your boss gave for short session duration and IP locking not being secure enough, I mean specifically?

I can't think of one and I'd love to know if I'm just being complacent?
Avatar of sb1977

ASKER

He doesn't have a good reason, it's just that we had an outside company do a security audit on our site and I have been tasked with fixing the issues they gave us.  

I just had an idea regarding using the secure cookies I mentioned above.  I'm thinking about creating a random number or id when a session is created and storing the value in a secure cookie and in the session.  The user will only be able to send the cookie on secure sites (in my case, the Weblogic server) where I will have a filter that takes the value from the session and compares it to the value in the request.  

What do you think?
Avatar of sb1977

ASKER

I think I'm going to stick with the idea I had above, but I think bloodredsun's point about tracking the user's IP was very helpful, so I will mark that as the accepted solution.  

Thanks again for all your help!
Cheers sb :-)