[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1381
  • Last Modified:

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!
0
sb1977
Asked:
sb1977
  • 5
  • 5
  • 5
  • +1
1 Solution
 
bloodredsunCommented:
>>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.
0
 
sb1977Author Commented:
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.
0
 
bloodredsunCommented:
Not unless you have your session duration set to an insanely long time. I'm currently at a bank where the default session is 6 minutes which is seen to be plenty long enough for people to browse, but short enough for them to be safe.

On top of that, I would recommend that you store the IP address of the user in the session and check it each time. That way you "lock" the session to the user at that IP so if someone else somehow managed to generate a valid jsession id, they would still not be able to acess the data as the IP would not match the one stored at login/authorisation.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
actonwangCommented:
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        
         
0
 
actonwangCommented:
>> Actually you should need to be worried about
                ...you shouldn't ...

Typo,sorry:)
0
 
sb1977Author Commented:
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?
0
 
actonwangCommented:
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.
0
 
bloodredsunCommented:
>>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.
0
 
TimYatesCommented:
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...
0
 
actonwangCommented:
basically, what you need to is just put all your sensitive pages under https, not necessary to use ip logging anyway. The reasons above.
0
 
sb1977Author Commented:
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?
0
 
actonwangCommented:
cookie for session is set by app server. The name might not be JESSESIONID.
0
 
bloodredsunCommented:
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?
0
 
sb1977Author Commented:
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?
0
 
sb1977Author Commented:
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!
0
 
bloodredsunCommented:
Cheers sb :-)
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 5
  • 5
  • 5
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now