I have an SPA on domain.com.
I have an API on api.domain.com.
User from SPA sending request (with login and password) to API.
Everything fine - he gets httponly cookie for api.domain.com ans
JWTokens in respose body.
Strange we can update cookie for api.domain.com from JS (from domain.com).
But then SPA makes anther request to API (api.domain.com/refresh), and
Chrome notes that cookie must have option SameSite (none), or cookies
will be omited! So we fail to refresh JWTs.
But if we do this (SameSite none), we can make another SPA2 on domain-bla-bla.com
and if user have already cookie for api.domain.com we can
make request to api.domain.com/refresh from this SPA2. And this is
rather kind of bad situation.
How we can split SPA to domain.com & API to the api.domain.com in secure
manner?
#1 I have some idea 😐 So.
It wil be wounderful to have cookies for different pairs, for example:
UI on domain.com and API on api.domain.com - one cookie.
UI on api.domain.com and API on api.domain.com - another one cookie.
UI on domain-bla-bla.com and API on api.domain.com - another more cookie.
But cookies generates on api.domain.com.
Maybe I'm wrong, but I can get origin header on api.domain.com and make
cookies name like api_domain_com_cookie_name.
Than on cookie check I'll get origin header on api.domain.com and check
my cookie. api_domain_com_cookie_name.
But from another origin domain-bla-bla.com.
Ill will check it own cookie named: domain_bla_bla_com_cookie_name - and
it will be empty.
It looks like it will secure with option SameSite (none), will not it?
#2 Or just have list of posible origins.
Is one of this ideas is safe enough?
Is it posible to set origin header with some custom lib like axios (user have normal browser like Chrome or Firefox or IE)?
Sorry for blockqoutes, parser alerts that i have code in the message =\
Related
I have a web app that makes a POST request to:
https://localhost:5000/processOneTapCredentials
This endpoint sets some data in flask.session, and then returns a redirect to another endpoint (https://localhost:5000/login/success). I can confirm it attempts to set the session. The response headers for the first endpoint (the 302 response) includes:
On the second endpoint, the session is empty though. I see that when the 302 is processed, there is no cookie header set in the headers:
So the flow is:
Web app makes a XHR request (POST) to https://localhost:5000/processOneTapCredentials
https://localhost:5000/processOneTapCredentials sets some flask.session info and returns a 302 to https://localhost:5000/login/success
https://localhost:5000/login/success gets invoked (I see in dev tools), but there is no cookie, so session is empty.
I have set the Flask key correctly, and the session works between redirects in other situations (such as when Flask-dance redirects to authenticate a user). So I must be doing something wrong.
What am I missing?
make sure your app['SECRET_KEY'] is not changing, and if you are redirecting to an external website or redirect from http to https you need to set your SAMESITE policy properly, with a SAMESITE='Lax' cookies are not forwarded, try setting it to None and see it the problem is related to your SAMESITE policy
I have directus API and admin app on localhost and I have frontend React app on localhost:3000. When I try to login via client.login method from React interface directus sets cookie to localhost (its admin app origin). But I need this cookie on localhost:3000 where my actual app located.
Set cookie header is like that:
directus-test-session=4JCvIJhNxCovLAvCwkSulylc8ZYq1iok4EQ3%3A%3A5b84ad5310ba25a7129ed57448136e13; path=/; expires=Sat, 04-Jan-2020 14:06:49 UTC; HttpOnly
Also google console provides warning like below:
A cookie associated with a cross-site resource at http://directus.test was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure.
I need to set cookie to localhost:3000. How can I do this? Thank you in advance.
I'm not sure if Chrome allows you to set cookies to localhost on a specific port at the time of writing*
As for the warning thrown: we can't set the SameSite attribute as that will kill support for cross domain cookies entirely. You can either host your end project on the same (sub)domain as Directus or use the JWT mode for authentication instead. (When using client.login, set mode = 'jwt').
We can consider making the cookies Secure by default, but that would possibly hinder localhost development, as that requires a HTTPS connection for the cookies to be sent.
* Chrome (and the other browsers) have been updating their cookie policy very frequently lately to fight third party tracking.
tl;dr, an XHR client in domain A is sending a request to a server in domain B, server responds with a Set-Cookie with Domain=A (the client's domain, the XHR's Origin), all CORS headers set correctly, should it work?
It's well known that one can't set a cookie to another domain. ( How to set a cookie for another domain
However given the following scenario:
Actors:
Client in domain A, a web based client
Server in domain B, setup with CORS headers permitting A as origin, including Access-Control-Allow-Credentials set to true
Communication flow 1 (baseline):
Client is issuing a simple GET request to the Server
Server responds with a cookie, and sets the Domain property to be of the server (Domain=B)
Client is sending another HXR request and has withCredentials=true
The cookie is sent back to the server without any issues
Note: the cookie sent in step #1 is not showing in document.cookies, even if it was not set as httpOnly (since it doesn't
belong to the client's domain). Also attempts to get it from the xhr
via looking at the "Set-Cookie" header, you'll be blocked, by design:
https://fetch.spec.whatwg.org/#forbidden-response-header-name it will
even won't show in Chrome dev tools under the network tab! but it will
still be sent)
Communication flow 2 (my question):
Client is issuing a simple GET request to the Server
Server responds with a cookie, but sets the Domain property to be of the client (Domain=A)
Client is sending an HXR request and has withCredentials=true
The cookie is not sent back and doesn't seem to be stored anywhere
Why am I a bit surprised? Since the XHR origin is A and it requests something that sets the cookie to domain A (if I look in Postman I clearly see the Set-Cookie header being sent with Domain being the same as the request's Origin), and I have the most permissive CORS setting for that, what's the reasoning behind not letting me do it? (I was expecting it to fail, but still made me wonder)
Questions
Where is the best place in the spec/RFC that it clarifies that this won't work also for XHR where the cookie Domain equals the Origin
What is the attack vector in scenario 2 if theoretically the browser did allow the server to store the cookie if and only if the Origin is the same as the cookie Domain and the CORS origin allows that Origin.
Is there another way to make it work? Maybe it works but my POC was setup incorrectly?
Appendix: Reasoning
I'm looking for a way to have a cross origin CSRF using something like the Cookie to header token method, but due to the cross origin issue, it seems that it's impossible. The only workaround I thought of is sending the CSRF token as a header from the server, then the client can just save it as a cookie it can access later, is there any other way to do it? Is this considered secure?
A resource can only set cookies for its host's registrable domain. If Facebook were to use Google Fonts, and Google could use that to override Facebook cookies, that'd be pretty disastrous.
As for where this is defined, step 5 and 6 of https://www.rfc-editor.org/rfc/rfc6265#section-5.3 handle this. (Fetch largely defers to this RFC when it comes to interpreting the Set-Cookie header on responses.)
i'm making a web app in a restful way.
For my client side i'm using angularJs, the same is hosted at - lets say -
https://domain.com
My backend is built on spring boot and i call all the resources from a subdomain - lets say -
https://xyz.domain.com
Now when a user logs in , the backend sends an http only cookie to the client.
I can see the cookie in response header but its not being set in the browsers cookie.
After a bit of research, i have tried sending cookie with domain = .domain.com
but that didnt work either.
Is there a way i can set cookie coming from xyz.domain.com for my client side at domain.com
(Note - i'm not using www.domain.com )
Any help or clue would be great.
Thank you for going through my question.
The problem you're describing is related to cross domain cookie policies. I don't know your exact use-case, but looking at CORS and P3P headers should give you a good start. As an option, you can try setting your cookie manually via Javascript.
Making CORS working isn't enough, you also need to enable withCredentials in angular.
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
Example:
angular.module('example', []).config(function ($httpProvider) {
$httpProvider.defaults.withCredentials = true;
});
I have a situation where my web application will respond with cookie Rules=abcdefg for each request.
Request 1:
http : //hostname:8080/teja/axftyo (for this request I am setting cookie path as below, response from server)
Set-Cookie: Rules=HCE0F290B77137721C2F6107DD4B62F28;Path="/teja/axftyo"
Request 2:
http : //hostname:8080/teja/bcdefg
I assume that for request 2 Rules cookie should not be sent, but still the browser is sending this cookie in to the server.
How can I achieve the functionality of browser sending different cookies based on the path (/bcdefg) rather by my application name /teja
Thank you.
Cookie paths only work on a directory level. /dir/a and /dir/b are considered to be in the same scope for cookies.
/dir/a/ and /dir/b/, on the other hand, are distinguishable, so you could consider adding trailing slashes to your URLs.