I'm working on a web application that has to use different domains for access over http and https. Now I'm facing the following problem: While the user is accessing the http-domain, some information is stored inside the session. When the user makes the transition to https the information which session the user belongs to is lost (because the session id is stored in the cookie that is associated with the http-domain).
How can I reattach the correct session to the user after he has switched domains?
Is it possible to execute some java-code right before the redirect that is caused by requires-channel="https" is sent?
Edit: I was thinking there might be something specific in Spring Security that could be used, but so far I wasn't able to find anything in the documentation.
Edit 2: Just found out that what I probably need to do is to replace the ChannelProcessingFilter with a custom implementation. But I don't know what I have to do to make spring security to accept my new class instead of the default ChannelProcessingFilter. Note: I'm using Spring 3.0.
We solved the problem by supplying a custom ChannelProcessor that gets executed right before the default ChannelProcessor and sends a redirect that includes the jsessionid as an URL parameter. Then the default ChannelProcessor uses this URL and sends another redirect to the http-domain.
To change the URL-parameter back to the ";"-format for session ids we have some additional directives in the apache:
Header edit Location ^(.*)\?jsessionid=([^&]*)&(.*)$ $1;jsessionid=$2?$3
Header edit Location ^(.*)\?jsessionid=([^&]*)$ $1;jsessionid=$2
The URL is then evaluated by the tomcat and continues the same session on a different domain.
Check out this post for information/resolution on this - Session lost when switching from HTTP to HTTPS in PHP
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.
I have java web application using struts 1.x. Recently my application has gone through penetration testing and our testers found some security holes. Let me explain. In my application i have 2 users called ‘Admin’ and ‘user’. First our PenTester logged to my application as ‘Admin’ and they use ‘Burp tool’ to intercept the request and copy the whole request content into notepad and then forward the request. Now My application log in as ‘Admin’. They use another browser instance to login as “user” and use burp tool to intercept the request. This time they removed the whole request content and copy back the whole request content of ‘Admin’ and then forward the request. Now my application logged in as ‘Admin’ without asking any user id/password? How to restrict this situation? I already stored userid in my session variable after successful login of each user. The moment they intercept the request and copy the ‘admin’ request content, my session variable userid also changed to ‘admin’. How to validate this situation? Your help is really appreciated.
That is not really that much of an issue since the first part "copy the whole request content" is not easily doable if you have a proper HTTPS / SSL connection. That only works if the PC the user is logged in on as an admin is compromised in which case: nothing you can do about it anyway because they can just sniff the keystrokes and get the plain password.
If on the other hand you communicate without the S, namely just HTTP then the solution is: get a certificate and switch to HTTPS.
Apart from that your application can pin a session to an IP which means if the session id / cookie is stolen and someone else uses it you can detect an IP mismatch and ask for credentials again.
To prevent direct replay attacks like copying the request and sending it again you can introduce a hash that incorporates the timestamp or alternative measures, see. How do I prevent replay attacks? . The problem however is that copying the entire request means copying the cookies as well and if the "admin" cookie is copied this measure will not prevent you from "generating" a new hash based on the now admin user.
I have a problem with cookies handling using java:
we have a tomcat cluster managed by apache to serve multi application, all on the same domain.
First problem:
Creating cookies using java, setting the cookie.setPath("/") to cover all domain pages, in order for all applications to be able to read the cookie, the scenario,
i'm in application1, app1 creates the cookie, setting the path of cookie, to the /app1/
moving to app2, app2 can't read the cookie, it creates the cookie with another path, /app2/
what is going wrong with ?
Second problem:
The perfect code for cookie deletion works fine with me, on our servers,
but moving out to different servers, the code can read the cookie, so no domain problem there, but can't delete it.
Again what is going wrong with java handling cookie ?
Do i have to use javascript better than java for cookies handling ?
You should set the domain, not the path:
cookie.setDomain("example.com");
Now all applications hosted on example.com will be able to share the same cookie. For example applications on app1.example.com and app2.example.com will be able to see this cookie.
I have an application(client application) hosted in a Tomcat server and this application has to be integrated as a Tab in another application(parent application). In the Parent application the user authentication is done. in the Parent application Html we are using iframe to integrate the client. Everything is working fine except this. The Problem is, if some one knows the URL they can access the client application. How can we avoid this.? we are using JAVA,SERVLET,HTML,Tomacat as technologies.
Thanks :)
One of possible solution is token based authentication.
The parent application should add special token either as a URL parameter or as HTTP header. The token should contain authentication information in encrypted form. "Client" application should extract the information and decide whether authentication passed or failed. In order to guarantee that no-one can copy this token and then get unauthenticated access to your application you should make the token to be one-time or limited in time range.
You can also use x-frame-options in your header. I found this article with some quick googling: http://www.jtmelton.com/tag/x-frame-options/
This will prevent your app from loading in frames except for the domains which you allow permission. You might check into browser compatibility, I'm not sure when this was implemented in different browsers.
Also, you can check the 'host' and 'referrer' header fields to check that requests are coming from a domain you trust before sending a response.
OAuth is the standard for authorizing third party apps. You should check into that as an authentication approach.
None of these will give you a completely secure app. You should consider consulting with a security expert.
From parent application add cookie and from child application get that cookie and validate user.(if both are running on same domain).
I am trying to login and retrieve status information from a HTTPS URL via Java programming. I login through /login.cgi, providing the username and password with a POST request to that script.
The script then verifies the credentials and creates a specific cookie (with session information, user name, etc.) and then immediately calls a Location response header to /home.cgi. Which, I'm guessing, the /home.cgi script verifies the cookie information before continuing to load. Otherwise, it just reverts back to the /login.cgi page.
All of this works fine within a browser because of the way browser's handle cookies/sessions correctly. However, within Java, this is very tricky because I can not get the appropriate cookie to send as a request to subsequent pages. I can not get the correct cookie because I am unable to get the HTTP response back (which holds the correct "Set-cookie" value) in between /login.cgi creating the specific cookie and it calling Location /home.cgi.
Is there something I'm missing or is there a better way that Java can handle cookies similar to a browser? (is there a cookie store, etc?)
Thanks for the help,
Steve
Cookie management is by default not enabled in the java.net HTTP API. If you don't need any specific handling or cross-application cookie persistence (the cookies will be deleted when your application terminates), you can simple enable it with
CookieHandler.setDefault(new CookieManager());
How are you making the HTTP connections and managing cookies?
I would recommend just using commons-httpclient rather than managing this yourself. It will automatically manage cookies for you.