I have a problem related to subdomain and https request.
I am trying to route from http to https where my http address is subdomain.domain.com and https address is domain.com/subdomain. But the problem is when i switched from http to https i loose my session variables.
How can i persist my session variables in both http and https requests.
Thank you.
The session is probably tracked by a cookie.
Cookies have a domain associated with them, in this case this would be "subdomain.domain.com". For a different domain, even if it is the parent domain, the cookie will not be provided by the web browser.
I think there are ways to make a cookie valid for all subdomains under a given domain, but you have to look into the documentation of the software you are using for that.
For any more information, we really need more detail about what software you are using to keep this session. Standard PHP sessions? Or something else?
Related
I have a spring app running on tomcat and I've set up two connectors 8080 and 8443. I use 8443 for authentication and 8080 for the application. After authentication JSESSIONID is added with secure notation and thus it's not available in HTTP.
How can I create two types of authentication when authenticating with HTTPS so that HTTP would also be authenticated. I set my authentication with:
SecurityContextHolder.getContext().setAuthentication(authentication);
This should work out of the box. The session cookie that's set is shared for http & https. Examine the cookie and verify if the domain, path & protocol are correctly set. Also you should verify your spring security configuration. Example here
Also you should really be using only https instead of serving any content through http - the overhead is insignificant while giving a big security benefit.
You can not do it and it has nothing to do with Tomcat.
The issue is the browser will not send the same cookies that it was using for HTTPS to the HTTP URL. You will have to login twice. You could potentially do some very nasty things to somewhat accomplish this (like allowing session ids in the URL and/or some javascript to perform some autologin) but I highly recommend you do not do that.
The only solution I can see to make this work safely might be to use SAML single sign-on. Otherwise you really should serve everything you want authorization for under HTTPS (ie requires login).
I'm struggling with CORS and a SSO configuration between two WAS servers using LTPA key share.
CORS calls from server1 (domain1) to server2 (domain2) work fine if I don't have authentication on server2 (meaning the cross domain Ajax call works), but it doesn't if I have.
The context is: The web client logs into domain1, one part of the UI needs to display some data coming from server 2 (domain2). Server 1 and server 2 share the same LTPA key with the same realm. That works fine, I can make manual calls (with curl for example) to domain2 using the LtpaToken2 from the webclient obtain from domain1.
The problem is: When I make the CORS call from the web client, I use withCredentials to true, but withCredentials includes cookies from the remote domain, and of course I have no cookie yet since the browser does not know the domain2 yet. What I need to do is include the LtpaToken2 cookie from the local domain (domain1) when doing the cross-domain ajax call to domain2. That way I will be authenticated. But because of the cookie cross domain policy I'm stuck.
Am I approaching the problem in the wrong way here? How would you handle that: doing a CORS call to a yet unknown domain using the LtapToken from the local domain?
Thank you very much for your help!
I'm building a Sinatra app which needs to use a session variable for one very specific thing. The session variable is set when the user is looking at an SSL enabled page.
I'm using Heroku's piggyback SSL, so the SSL url is something like https://myapp.heroku.com
However, the app itself is hosted at my url, myapp.com
Is there a way to make my session variable, which is set while on the ssl / heroku domain name, available to my app while while on my domain name?
Unfortunately no, since the cookie is tied to the domain. What you'll have to do is either allow authenticated users to use the https://foo.heroku.com domain, and reserve your nice domain for the landing page & other unauthenticated pages.
That, or pay $20 for heroku's SSL add-on.
(I ran into this exact problem in http://appkickstand.com and I chose to just deal with the heroku url for logged in users)
You should look for cross-domain cookies manuals, check this.
But i don't see many reason in setting cookie through secured channel and transmitting it later via raw HTTP, where everyone could sniff it.
I have read on some blog (sorry for not mentioning the reference but I can't find it anymore) that you will lose all your work on securing your site if you redirect a user from an https page to an http page.
So, could someone please explain to me if I am right or wrong here in the following scenario:
Is it right practice to use https on the login page then redirect him to Admin Page with http, or will this will create a security issue like Session Fixation hijacking, stealing session, etc.?
Or must I keep the Admin Page also in https?
Another side of the question is: will https allow caching of static files?
I have read other articles here but I am still confused as some say 'yes' and some say 'no'; also some say it depends on browser.
In your instance (in only securing the login page with HTTPS) while login details will be protected (e.g. username/password), your users will be susceptible to Session Hijacking.
Whether you use a mixture of HTTP/HTTPS or full HTTPS depends on your situation. Amazon for instance, will use HTTPS for the login, but you'll browse the site with HTTP, but as soon as you go to a sensitive area (Order details screen, change account/password details etc.) it switches to HTTPS and asks you to re-authenticate. Re-Authenticating the user after switching from HTTP to HTTPS is the key to stop Session Hijacking because you're effectively issuing a new Session token. So if a user steals the session token, they still don't have your username/password and can't access your account section.
If the admin area is particularly sensitive then just HTTPS the whole thing. Google found the overhead from using full HTTPS was between 1-5% overhead on the CPU, hardly anything basically.
As for caching static files on HTTPS I'm not sure, but this SO post suggest it'll cache as normal Will web browsers cache content over https
Everything must be used with https. If you switch over to http, everybody can see the content being sent, which means those security issues you mentioned will emerge.
The reason is that you have to identify your client in order to assign access rights in your admin site. One possibility to do so, is sending back a token (some hash or whatever). Depending on the token you know if it's an authenticated client or not. But everybody else does see this token => security issue.
Of course you could use the previous https session to exchange a private key. And use it to encrypt your http stuff somehow. But this is a bad idea, since https does this much more conveniently..
I am currently working on the authentication of an AJAX based site, and was wondering if anybody had any reccomendations on best practices for this sort of thing.
My original approach was a cookie based system. Essentially I set a cookie with an auth code, and every data access changed the cookie. As well, whenever there was a failed authentication, all sessions by that user were de-authenticated, to keep hijackers out. To hijack a session, somebody would have to leave themselves logged in, and a hacker would need to have the very last cookie update sent to spoof a session.
Unfortunatley, due to the nature of AJAX, when making multiple requests quickly, they might come back out of order, setting the cookie wrong, and breaking the session, so I need to reimplement.
My ideas were:
A decidedly less secure session based method
using SSL over the whole site (seems like overkill)
Using an iFrame which is ssl authenticated to do secure transactions (I just sorta assume this is possible, with a little bit of jquery hacking)
The issue is not the data being transferred, the only concern is that somebody might get control over an account that is not theirs.
A decidedly less secure session based method
Personally, I have not found using SSL for the entire site (or most of it) to be overkill. Maybe a while ago when speeds and feeds were slower. Now I wouldn't hesitate to put any part of a site under SSL.
If you've decided that using SSL for the entire site is acceptable, you might consider just using the old "Basic Authentication" where the server returns the 401 response which causes the browser to prompt for username/password. If your application can live with this type of login, is works great for AJAX and all other accesses to your site because the browser handles re-submitting requests with appropriate credentials (and it is safe if you use SSL, but only if you use SSL -- don't use Basic auth with plain http!).
SSL is a must, preventing transparent proxy connections that could be used by several users. Then I'd simply check the incoming ip address with the one that got authenticated.
Re-authenticate:
as soon as the ip address changes
on a time out bigger than n seconds without any request
individually on any important transaction
A common solution is to hash the user's session id and pass that in with every request to ensure the request is coming from a valid user (see this slideshow). This is reasonably secure from a CSRF perspective, but if someone was sniffing the data it could be intercepted. Depending on your needs, ssl is always going to be the most secure method.
What if you put a "generated" timestamp on each of the responses from the server and the AJAX application could always use the cookie with the latest timestamp.
Your best bet is using an SSL connection over a previously authenticated connection with something Apache and/or Tomcat. Form based authentication in either one, with a required SSL connection gives you a secure connection. The webapp can then provide security and identity for the session and the client side Ajax doesn't need to be concerned with security.
You might try reading the book Ajax Security,by Billy Hoffman and Bryan Sullivan. I found it changed my way of thinking about security. There are very specific suggestions for each phase of Ajax.