My application is using websphere 6.1.
And there is no configuration done for setting the cookies secured.
But when I test my application's cookies using mozilla firefox addon : firbug, I can see that few of the cookies are secure and few of them are not.
So I want to know what parameters decides that a cookie should be secure or not.
Sorry for not sharing code / cookie information due to some security constraints.
Related
The Problem
When redirecting from a servlet using response.sendRedirect(redirect_url);, the JSESSIONID cookie is not passed by the browser to the destination. A new JSESSIONID is created for every redirect, and it is impossible to track the user.
Note: This problem is only occurring on my new server implementing https and a domain name; the session ID is properly tracked when I run the web app locally or on another server without SSL or a domain name. Edit: I have set up another site on my server without SSL, and the issue persists. This seems to narrow the issue down to having a reverse proxy Apache.
An Example
The Login servlet on my web app attempts to store the user information in a session attribute then redirects to the MyCards servlet. I am using a redirect so that the URL will display mydomain.com/MyCards instead of mydomain.com/Login. The MyCards servlet attemtps to access the session attribute but finds nothing, and therefore redirects back to the Login servlet. This worked perfectly before deploying the project on my new server with SSL and domain name.
My Setup
Ubuntu 20.04 on DigitalOcean droplet
Apache Web Server (apache2) ... I have enabled mod_sessions, not sure if that's relevant.
Tomcat 9
Reverse proxy in Apache VirtualHost to Tomcat (I can post my .conf file if requested)
A redirect in Apache VirtualHost from HTTP to HTTPS
JDK 11
Possible Solutions
Using a forward instead of a redirect. The session ID is not lost when using requestDispatcher.forward(request, response);. As I mentioned above, I want the URL to reflect the destination for an intuitive user experience, which does not occur when using a forward.
Implementing your own session cookie, as in this answer, and manually storing sessions with a map, as in this answer, which strongly advises against such a facility. Based on my understanding, doing so poses security threats to user data. Also, if the browser is not passing the JSESSIONID cookie, I don't understand why it would choose to pass the manually implemented cookie unless the SameSite attribute is set to None (also bad).
Verifying that the webapp's context.xml does not have cookies="false" configured. Done that.
Using encoded URLs with response.sendRedirect(response.encodeRedirectURL(url));. Again, for the sake of having a clean URL (which the user could bookmark or type in) is preferable, and encoding the session ID into the URL is not.
Using relative URLs instead of absolute URLs...
"A session is only maintained if the redirection is being sent on the same port, host and webapp [and protocol?]. If redirection is done within the same application, using relative paths is the best practice." I tried both redirect_url = "/MyCards" and redirect_url = "MyCards", no luck.
Possible Reasons
Perhaps I am unknowingly switching between HTTP and HTTPS, which is a change in protocol and will not preserve the session ID. Of course, my intention is to remain secure and stay exclusively in HTTPS. Edit: I have set up another site on my server without SSL, and the issue persists. This seems to narrow the issue down to having a reverse proxy Apache. When accessing the web app directly on Tomcat (i.e. with <server_ip>:8080/MyWebApp), the session is tracked properly on redirect. However when using mydomain.com, the session ID is lost on every redirect.
Something to do with naked domains.
Other?
Edit: Maybe the issue is occurring because of the way the client, Apache, and Tomcat interact via the reverse proxy. Does the proxy cause the domain/port to change on every request/response?
My Questions
Why exactly is the session ID lost when using a redirect to a relative URL to a servlet in the same web app on the same server? Shouldn't the redirect occur entirely on the server-side, preventing a new request/session from being created? Since the relative URLs (which I thought would preserve the session) did not solve the issue, does this indicate some problem with my server setup (e.g. unintentional switching between protocols)?
What is the best practice for maintaining the user session ID, even when the user has cookies disabled? Is there no way around URL encoding when cookies are disabled? Or should the app be implemented exclusively with forwards rather than redirects? If so, is there a workaround to changing the URL to reflect the destination?
Note: this is my first post, so I don't have the reputation to comment. I will edit the post with any needed information.
Apologies if I sound bad.
I have a xyz.war that does some authentication and sets a cookie(with HttpOnly set so I can not expire it via javascript) so that when the user logs-in for the next time the session is maintained. Now, given that I have the access to the Tomcat that is hosting the xyz.war how can I write a Java program that could expire/delete the cookie? I can create a .war of the java project and host it in the same Tomcat and access it from client side via a api.
You would have invalidate the session in xyz application. Removing (thus beeing able to midify) cookie by third parties would be a security hole.
My application is running in jboss 7 and the sessions are being maintained by using the jsessionid cookie, which is marked secure and httponly. But even with this, if I am able to get any user's jsessionid cookie value, I will be able to spoof as the user. Is there any way to prevent this?
When you have a session for a user on your server, you need to match a request from a user to its session, it's the goal of the JSESSIONID cookie.
This is why you need to secure it by adding "secure" (this cookie will only be sent over https to prevent network sniffing) and "HttpOnly" (to disable access to this cookie by client javascript code) options.
You can add other mitigation methods by checking change in user's IP address (but will break 3G/WIFI change for legit users), user agent string, ...
But in practice, if you have access to the JSESSIONID cookie you can have access to these data too.
You can take a look at OWASP Session Management Cheat Sheet for more :
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
I'm developing an environment with 2 webapps deployed in Tomcat 7. One authenticate users using form, openid, remember me cookie or x509 cert. This one works as expected and use the Remember me cookie to authenticate properly when generated.
The problem resides in the second one (the client):
When the login request comes back to the client from the first one, I don't see any cookie. I'm pretty sure they are in the same domain (localhost) and the cookie path is "/" but the browser (firefox) is not sending the cookie to the client.
If I want to use the generated remember me cookie to authenticate in the client, do I need to include all remember me cookie stuff from Spring's security?
Is the remember me cookie a good approach? Do I need something like siteminder or other better approaches?
Thanks in advance. Answers will be voted
Check the cookie information when it is sent back from the server (use Firebug to monitor the network traffic if you're using Firefox).
Check the domain and path, and also whether the cookie is flagged as secure. If the remember-me cookie is issued over a secure connection it will be marked as secure and the browser won't send it over HTTP.
If this is the case, you have to explicitly override it (though you're better to use HTTPS throughout). There's a use-secure-cookie attribute in the remember-me namespace element which you can set.
When I am using HTTP protocol, there is no issue with sessions. But when I am using HTTPS protocol, I am facing problem in JSP. When it is moving from one tab to another tab, session is automatically getting expired. How can I resolve this issue?
Basically, there's no difference in JSESSIONID management whether TLS/SSL is enabled or not.
Most app-servers use cookie and/or URL-rewriting for JSESSION management.
The major different I know is that, when you use “secure cookie,” JSESSIONID can be managed using both cookie and URL in HTTPS, but only with URL in HTTP.
So, if the transition is across HTTPS and HTTP, the problem as you say might be happen.