I have a Webapp (HTML, JS, PHP) on an Amazon cloud server which is integrated in our companies network. Lets say the servers name is
dev-myapp.cloud.myentity.mycompany.com
This app is using the companies global SSO login by getting an oauth token from the SSO login page and then sending client, secret and callback (as usual). If Login is successful, the SSO login redirects to my callback (which in that case is my apps url above)
The SSO login creates many cookies in the browser. Most of them are flagged as secure but also some are not. For all of this cookies I now get an error
Cookie "xxx" will be soon treated as cross-site cookie against "path_to_any_of_my_sources" because the scheme does not match
I get this error for every script which is loaded (HTML, js, PHP, css) with FireFox.
The domain of the created cookies is
mycompany.com
so there should be no cross site at all.
What can I do to remove this hundreds of warnings, which makes debugging really annoying
If you need more information please let me know. Please understand I cannot provide you with real data from my company.
I was able to fix this same problem by clearing my cookies in the browser.
Related
As there is currently no Auth0 SDK for SvelteKit, I am learning (or at least trying to learn) far more about authentication than I originally intended when setting out to incorporate Auth0 into my SvelteKit app (including server side authentication). The documentation is a little confusing (or maybe it is just massive, or maybe I am just not that bright), so I was hoping to describe my auth flow here for critique (in the hope that this will be helpful to others in the future).
I have reviewed this great post about SPA auth as well as Auth0's educational offerings. Still I am not sure I am connecting the dots properly. Here is my flow. All of this occurs over SSL only.
I create an Auth0 client on the client side using their client SDK (#auth0/auth0-spa-js). That client performs authentication via the Auth0 popup.
Once authenticated, everything works as expected on the client side. But if I want to control access to routes on the server side, I need to get information back to the server. So...
After authenticating, Auth0 creates an ID token (a signed JWT) which is stored in the browser's local storage. I save it as a session cookie (with SameSite=strict; HTTPOnly; Secure; options set) so that it gets passed back to the server with requests for route authorization.
So let me pause right here...I understand that (at least according to some including the Auth0 educational video linked above) the ID token is not supposed to be used for authentication and should never be passed around. That is what an access token is for. However, in this scenario where the exchange is all first party (my client, my server), it is my understanding that it is "ok".
However, it does make me nervous that the Auth0 SDK is not setting the cookie itself. This makes me wonder if I am Doing It Wrong™.
On the server I validate the id_token using a public key, and can then save user details, etc. on the backend if I wish, and allow access to appropriate routes (via hooks.server.js in the case of my SvelteKit app).
When the user logs out, or if the token expires, the cookie is removed.
(As a side note, I have yet to figure out how to refresh the ID token when it expires as the Auth0 client SDK does not seem to ever update the ID token in the browser storage even if it is expired.)
Is that a secure and typical way of going about it?
(For a work in progress working example, see my svelteauth0 repo.)
Background: I have a javaee webapp deployed on tomcat which uses form based authentication. When the web server receives a login request, it sends the request to a dedicated authentication service which validates user login (User id and password). After successful authentication user's session is maintained in the web server.
Problem: I have written a simple webpp source code here, to simulate the scenario. On successful login the current HttpSession instance is invalidated and new instance is created. For each request for a post login page, the session is validated. A new JSESSIONID cookie is set which is used to identify the user during the session until session is expired or user logs out. This cookie can easily viewed in browser's dev tools. If I copy the cookie and set this in a different browser via JavaScript (document.cookie="JSESSIONID=xyzz") and then try to access a post login page, the server identifies it as a valid request and session is validated successfully. The post login page is served without user being challenged for user Id and password.
POC: User opens chrome and enter the URL http://localhost:8080/mywebapp/ and logs in with admin and pass1234. On successful log in the home page http://localhost:8080/mywebapp/home is shown. Now the JSESSIONID cookie is copied and set in FireFox. User enters http://localhost:8080/mywebapp/home in Firefox and is shown the home page without being challenged for userId and password.
Question: How can this be prevented wherein same session is getting replicated over multiple browsers?
You can't prevent this specific case of simply copying the cookie from your own browser (or by copying the cookie value from a HTTP payload copypaste/screenshot posted by an ignorant somewhere on the Internet). You can at most prevent the cookie getting hijacked by XSS or man-in-middle attacks.
This all is elaborated in Wikipedia page on the subject Session Hijacking of which I snipped away irrelevant parts (either already enforced by Servlet API, or are simply not applicable here).
Prevention
Methods to prevent session hijacking include:
Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key (though ideally all traffic for the entire session[11]). This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack. In response, scientists from the Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by correlating the application session with the SSL/TLS credentials[12]
(snip, not relevant)
(snip, not relevant)
Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.
Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, two legitimate, closely timed requests from the same client can lead to a token check error on the server).
(snip, not relevant)
In other words:
Use HTTPS instead of HTTP to prevent man-in-middle attacks.
Add a checkbox "Lock my IP" to login form and reject requests from different IP associated with same session in a servlet filter. This only works on users who know themselves they have a fixed IP.
Change session cookie on every request. Interesting at first sight, but breaks when user has same website open in multiple browser tabs/windows in same "session".
Not mentioned, but make sure you don't have a XSS hole anywhere, else it's very easy stealing cookies.
Last but not least, I'd like to make clear that this problem is absolutely not specifically related to Servlet API and the JSESSIONID cookie. All other stateful server side languages/frameworks such as PHP (PHPSESSID) and ASP (ASPSESSIONID) also expose exactly the same security problem. The JSESSIONID was previously (decade ago orso) only a bit more in news because by default it was possible to pass the session identifier along in the URL (which was done to support HTTP session in clients who have cookies disabled). Trouble started when ignorant endusers copypasted the full URL with JSESSIONID inside to share links with others. Since Servlet 3.0 you can turn off JSESSIONID in URLs by enforcing a cookie-only policy.
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
See also:
How do servlets work? Instantiation, sessions, shared variables and multithreading
How to prevent adding jsessionid at the end of redirected url
remove jsessionid in url rewrite in spring mvc
What you have stated is called session hijacking. There are many good answers on how to prevent it.
Using same Jsession ID to login into other machine
we can use Encryption or hide JSESSIONID using Browser control.
Thanks
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..
We have an implementation understanding with a merchant to create our domain cookies when user is on his site. Now in FF assuming that third party cookies acceptance is set we are able to create the cookies and flow works fine. But the issue is that after the cookie is created and third party cookie is disabled later - the request to load an image from merchant site page to ours site - we do not receive the cookie details.
Is it an expected behavior or we need some special mechanism to get the cookie?
Please help.
You may already know this but cookies are domain based. You can only access cookies on requests for the same domain.
If your image is displayed on sample.com and your the url of the image is sample.com/img.jpg then when the request is made for the image the cookies will be sent along with the request.
On the other hand if the image is displayed on sample.com and the image url is yoursite.com/img.jpg then you won't receive the cookies for sample.com.
Also, dev.sample.com and sample.com are different domain names.
Hopefully this helps clarify why you can't receive cookies. This behavior is mainly security related to prevent websites from sniffing cookies from other sites.
I have a website that I would like to allow both Forms and Windows Auth for. My problem is that it seems that when you setup IIS to allow both anonymous (Required for forms auth) and Windows auth that the browser won't send the user's network credentials.
It just uses the anonymous login. Is there any way either in IE8 or IIS to have it try Windows Auth 1st and then fall back to Anonymous?
Thanks for any help.
You can't ask for HTTP authentication (whether that's Basic Authentication or Integrated Windows Authentication) without causing the authentication dialogue box to pop in the case where there are no credentials yet.
So in general for hybrid HTTP-auth+cookie-auth approaches you enable both anonymous and authenticated access for the bulk of the site, but allow only authenticated access to one particular script.
When the user accesses a page without either kind of auth, you spit out a page with a login form for the cookie-based auth, and also a link to the one URL that allows only authenticated access. The user can fill out the form for cookies&forms auth, or hit the link to log in with HTTP auth instead.
If the user follows that link, they will be given a 401 response and must provide HTTP authentication, either through the auth dialog, or potentially automatically using integrated Windows authentication. Once this has happened once, the browser will start submitting the same credentials to every future page, so IIS will decode the credentials to give you the expected REMOTE_USER when your main site scripts are run.
Browsers will only submit the credentials to pages in the same directory as the 401 script, or subdirectories of this. For this reason it is best to put the HTTP-auth-required script in the root, for example as /login.aspx.
However, there are a few browsers that won't automatically submit credentials for further pages, and require every HTTP request to respond 401 first, before sending the request again with credentials. This makes optional-auth and hybrid-auth schemes impossible (as well as making browsing of protected sites much slower!). The only modern browser that does this is Safari. You may not care, as Safari's support for Integrated Windows Authentication has traditionally been shaky anyway, and it can still use the forms+cookies auth type.