I can't seem to find the one right answer to my problem. I'm being overwhelmed with information I'm finding on the internet, and I have no idea what I should do.
My setup is as follows : Apache server (front end), Tomcat 6.0 (back end), RapidSSL certificate is on the Apache server, my site is made up of Java Server Pages.
The problem :
I have a few pages that are under https, while the rest of the site pages are under http.
The login page I have, is under https, and I've noticed that when I login, and redirect to an http page, that the session is not being maintained. Its creating a new one, which results in the user being sent to my 'session expired' page, when really, upon a successful login, they would be redirected to a different page.
Questions:
Why is the session not maintained when switched from https to http?
How do I fix this problem?
I need the session attributes that are created on the http pages, to be present on the https pages, so when the user is then directed to an http page again, the session hasn't been recreated, and the attributes lost.
Please ask me any questions you feel are necessary in order to help me figure this out. I greatly appreciate any help I receive. This issue has become a stumbling block for me, especially since I obviously lack the 'expertise' to figure it out myself.
Allowing the user to use the same session after logging in is a security vulnerability. Tomcat by default does not allow sessions to migrate from SSL to non SSL pages.
You should change your logic so if a user is doing a login, the session is silently updated, and logged in instead of going to the session expired page.
It's likely that you're using "secure cookies" to maintain the session: these cookies don't propagate from HTTPS to HTTP. This is generally a good thing.
You can chose not to do this, but when you transfer a session from HTTPS to HTTP you have to take extra care that you don't allow it to be reused over HTTPS later, as it may have been compromised.
Are you using a simple reverse proxy to connect to Tomcat? If that's your case, use mod_proxy_ajp to use AJP to connect Apache HTTP Server to Tomcat Application Server.
I have the same issue, where some parts of the site are https, and some are http. I've found that with Tomcat, session cookies created over http carry over to https no problem, however session cookies created over https are lost when moving to http.
One solution I have found maintaining a session as the user travels the site, is to bounce the user around when they first arrive. I created a RequestFilter with the following code:
if (request.isSecure() && session.isNew()) { // session cookie created over ssl
try { session.invalidate(); }
catch (Exception e) { /* handle error */ }
String url = request.getRequestURI().replaceFirst("https", "http");
response.sendRedirect(url);
}
else if (!request.isSecure()) {
String url = request.getRequestURI().replaceFirst("http", "https");
response.sendRedirect(url);
}
This forces new sessions to non SSL to create a lasting session cookie, and then once a session exists, the user forwarded back to secure request. This results in the session staying alive.
Or here's an options that involves less bouncing around, just overwrite the session cookie with one that isn't secure:
if (request.isSecure() && session.isNew()) {
Cookie c = new Cookie("JSESSIONID", request.getSession().getId());
c.setSecure(false);
response.addCookie(c);
}
Related
I have two Spring Web applications that work together. I'm running the first application from the IDE on localhost, while the second one is running in docker on app.127.0.0.1.nip.io.
The two applications interact indirectly through the users browser by redirecting and POSTing between the two apps. This is slightly similar to how an SP and an IdP work together in SAML2.
In my case, the first application on localhost is sending a 302 to the second application. After doing some work, the second application sends an HTML page with a form an JS code to autosubmit it, back to my first application on localhost. The HTML looks similar to this:
<form method=POST action="http://localhost:8080/some/path">
...
</form>
My first application is using Spring Session with a session cookie, and this works just fine. However, when the second application makes the browser POST the form, the browser does not send the session cookie with the POST request.
When both applications are running in docker under .127.0.0.1.nip.io, the cookie is sent.
I've tried to find any hint if this behaviour is expected, and what headers or other bits the applications could use to influence this.
At this point, this is mostly an annoyance while debugging, but I'm concerned that once the two applications will run on different FQDNs and/or different domains, the browsers will also block the cookie being sent.
I've tested this with current versions of Chrome and Firefox.
The problem is the new(ish) SameSite cookie policy that covers exactly this case: another application is POSTing to a host via HTTP. The default now is SameSite: lax, which does not allow sending the first-party cookie values on this request.
The solution is to allow the session cookie to be sent by specifying SameSite: none. Be aware however that this might create security vulnerabilities. For my application, this is not an issue, so I can allow the cookie to always be sent, and especially when I run my application in the debugger.
For the production deployment, I will be able to tighten this, since both applications will run under the same domain (a.example.com and b.example.com), and both will use TLS, so I can set the session cookie to SameSite: lax.
Here's a decent explanation: https://web.dev/samesite-cookies-explained/
I have two domains. Something like:
1) www.mydomain.com
2) www.mydomain.virtual.com
Temporarly, i must redirect Domain 1 to Domain 2, so when someone use www.mydomain.com y redirected him to www.mydomain.virtual.com.
The problem I'm facing is that (only on internet Explorer) session object is now losted between my sub-pages inside my web. I créate a session on default.aspx, and when i redirect with response.Redirect to let's say main.aspx, the object has no value. Does anyone have any idea why? Thanks!
Sessions are stored on the server, but the client needs to keep track of the sessionid. Usually a session cookie is used to store the sessionid.
What is causing this behaviour is that the sessionid cannot be resolved. Probably because the domain name is different and the browser interprets this as a third-party cookie, which can be (and probably is) blocked by the browser.
Since the sessionid cannot be resolved, all session info on the server is inaccessible. The link is broken.
Is it an option to copy the entire website to the temporary location and redirect all calls made to the original website to the equivalent page on the temporary location?
Otherwise you can solve your issue by using cookieless sessions:
https://msdn.microsoft.com/en-us/library/system.web.configuration.sessionstatesection.cookieless%28v=vs.110%29.aspx
For more information concerning cookies:
http://erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains/
I need some help in resolving a strange behavior I came across while using Thinktectures Embedded STS locally in my ASP.net MVC application. I don’t see this issue on the server using ADFS.
The issue is
After I sign in into the application, most of the HTTP calls from then on are getting called twice.
The first HTTP request goes without the FedAuth cookie to which the server responds with a status code of 302 (redirect) and another request to the same URL is made but this time with the Fedauth cookie. I'm trying to understand what is causing the browser to send the first request without the FedAuth cookie and also why the server redirects to the same URL?
I also need help in understanding how the EmbeddedSTS URL gets resolved. I went through the code on Github but it is not very clear to me how the EmbeddedSTS url is resolved.
Any help is appreciated.
I was able to figure out the issue on my own.
This issue is related to cookie paths being case sensitive. My virtual directory in localhost was configured as ATSWeb but while making AJAX calls I am constructing the full URL with a different case for the virtual directory (atsweb).
Since the ADFS cookie was set with the path /ATSWeb, while doing the AJAX call the browser is not sending the Fedauth cookie to the server. This is leading to all sorts of issues.
You can read more about cookie paths at the links below.
http://www.allbacktomine.com/blog/2009/02/04/BrowserCookiesThePathIsCaseSensitive.aspx
Why are cookie paths case sensitive?
my question upfront is:
When changing from http to https: How do I enforce on Tomcat that the value of the JSESSIONID / (i.e. the session cookie) gets changed?
Here's my situation:
I assume we are having a potential security issue in our application and wonder how to fix it.
We run a JSF1.2 / Seam2 application inside of a Tomcat 6.x and force the usage of session cookies (no sessionid in URLs).
We allow http access, but when a user logs in we switch to https and stay on https.
We also do have a Filter that adds 'secure' to the cookie whenever the request is coming through https to ensure that the session cannot go back to http.
(somehow I thought Tomcat would do that automatically)
I noticed that the JSESSIONID doesn't change when switching between http and https.
This suggests to me that an attacker could potentially spy out the session cookie through http and then hijack the session.
So how can I tell Tomcat to use a different JSESSIONID when changing to https?
(Or if thats the default behavior: What could lead to this not happening anymore?)
Thanks for any hints/ideas!
some time (years actually) I posted this filter here that we use to renew the session ID after the login:
https://issues.jboss.org/browse/JBSEAM-2450
We call newSession() just after a login to mark the session-ID to be renewed on the next GET request (POST requests don't work well due to the restore of the view state, but the POST/REDIRECT/GET with Seam will issue GETs quite often).
You might want put it into your filter -- or you just mark your session to be refreshed in the next GET request. Just make sure that you don't renew your session when processing a JSF POST request.
Someone else also provided a Tomcat Valve to solve this
Best regards,
Alexander.
I read that a page which runs under an https connection cannot share an InProc Session (based on cookies) with another page (or the same for that matter) running under regular http. My site is running on Server 2003, IIS 6 and .Net 2.0.
After some experiments it appears that a page which stores data in session while being connected through https CAN subsequently access the data even if running under plain http.
So, is it possible or should I go over and look for flaws in the SSL configuration?
From MSDN:
When a user moves back and forth
between secure and public areas, the
ASP.NET-generated session cookie (or
URL if you have enabled cookie-less
session state) moves with them in
plaintext, but the authentication
cookie is never passed over
unencrypted HTTP connections as long
as the Secure cookie property is set.
So basically, the cookie can be passed over both HTTP and HTTPS if the Secure property is set to false.
I have avoided this issue by adding this to my Global.asax file:
void Session_Start(object sender, EventArgs e)
{
if (Request.IsSecureConnection) Response.Cookies["ASP.NET_SessionID"].Secure = false;
}
This means that if the Session cookie is created over HTTP, it will only be accessible over HTTPS.
IIS setting
In the IIS properties window, under the ASP tab –> Session Properties, there is a setting for “New ID on Secure Connections”
I fixed this intermittent issue for myself by setting this to false.
Searching for the problem doesn't turn up much chatter about it so far, still looking.
Edit: okay finding some stuff now.
Right it seems that it will work fine if both sets of pages are in the same application/website.
So I'd go ahead and carry on, feeling reassured.
If any of the above solution does not work try this. I have cracked this out after doing research of a couple of days.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
...
...
CookieSecure = CookieSecureOption.Never
});