I'm having a new problem with a cross-site JavaScript request and sending cookies, but only in Firefox.
I have this code
$.ajax({
type: "POST",
url: "https://server.com/page",
data: $('#formdata').serialize(),
xhrFields: {
withCredentials: true
},
success: function(html){
alert("Thank you for your submission")
},
crossDomain: true
});
}
(context: it is in an example of how CSRF attacks work)
https://server.com/page relies on a session ID cookie to be sent. The cookie has been set, with SameSite set to None and the Secure flag included. myserver.com has the Access-Control-Allow-Origin set to include the site making this request. It also has
Access-Control-Allow-Credentials: true
However, in Firefox, the session ID cookie doesn't get sent. I am sure it used to before my most recent Firefox upgrade. I checked in a different tab and the cookie is there, and does have the correct settings.
It works in Chrome and it works in Safari.
Does anyone know if Firefox has changed its policy recently? Is there a setting I can configure?
My Firefox version is 104.0.2 (64 bit) and I am running on Mac (Monterey).
Never mind, I found it. Firefox's Total Cookie Protection prevents pretty much all cross-site cookie sending. Arguably a good thing but if, like me, you do want to enable cross-site cookies, go to Settings in Firefox and Privacy & Security. Under Enhanced Tracking Protection, click on Custom and uncheck Cookies.
Related
I have a JSP with javascript code, running on a server with HTTPS. In this JavaScript I trigger a request to another (local) webserver like this:
let url = 'http:/localhost:3111/doSomePost';
$.ajax({
type: 'POST',
url: url,
contentType: 'application/octet-stream',
processData: false,
data: uint8array
})
This requires CrossOrigin to be enabled on the local webserver in order to work - I configured that part and it works.
But it only works in Chrome. Not in Firefox.
Firefox will give me this error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at
http://localhost:3111/doSomePost. (Reason: CORS
request did not succeed).
I can see in the network tab of firefox devtools, that firefox does not even bother to send the preflight request (the OPTIONS request). So Firefox just decides it won't send that request (and I suspect it to be because that local webserver protocol is HTTP).
I have now changed my local webserver to use HTTPS using a self-signed certificate as described here: https://www.baeldung.com/spring-boot-https-self-signed-certificate
Now, it works in Firefox and Chrome (after I manually add the certificate which is not valid).
I just wonder why chrome has no problem but firefox does.
UPDATE: corrected minor typo in error message
I've managed to find a better solution. Instead of switching the local webserver to HTTPS in order to get firefox working, I changed the above request to:
let url = 'http:/localhost:3111/doSomePost';
$.ajax({
type: 'POST',
url: url,
data: jsonWithBase64encodedData
})
This now qualifies as so called "Simple request" (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) again, and is being treated in a similar, and most importantly, working way in all browsers.
So I've been having issues sending cookies with a cross-domain request to a service. I've gotten to make it work in our CI environment, but not locally. Basically, I have an API at api.service.com, and it's accessed via AJAX calls run from clients at webapp.service.com. The API sets a cookie for .service.com via set-cookie. Then all subsequent calls to the API should include this cookie. This works as intended, when running from webapp.service.com. This will work in prod just fine. However, for obvious reasons, I'd like be able to develop the webapp locally, and run API calls against api.service.com from either local files or localhost service.
I understand that Chrome is a little iffy regarding saving cookies for local files, but I've addressed that, and it is not the issue. The cookie is, in fact, saving. It's just not sending that cookie with subsequent API calls. Here's the workflow I've got going on (with some genericized/censored product names):
An AJAX call POSTS to our API:
$.ajax({
method: "POST",
crossDomain: true,
xhrFields: {
withCredentials: true,
},
url: 'https://api.service.com/login',
data: data,
contentType:"text/plain",
dataType: "json",
success: function(data){
...
}
});
The CORS stuff is set up to allow credentials and this origin (the allowed origin updates dynamically, doesn't use *. So we get this cookie back: cookie:service-token=7f7d251ebeec37f7c0815....; SameSite=lax;Max-Age=2629744; domain=.service.com; path=/;
It shows up in Chrome like this:
Request cookie
I know for a fact that this actually works to save the cookie. However, perhaps not how I want. I go into Chrome's cookies, and it updates properly as seen:
Chrome saved cookie
The problem I'm seeing there is that its "send for" value is "same-site connections only". I have no idea how to originally set that for Chrome to treat it as "any kind of connection." I think this is the reason that, when I send another AJAX call, that cookie is not included in the request.
I've seen other posts like this that were resolved by adding crossDomain and/or withCredentials to the AJAX call. This did not resolve it for me. This is a subsequent call to the API:
$.ajax({
url: 'https://api.service.com/getTheThing',
crossDomain: true,
xhrFields: {
withCredentials: true
},
success: function(data){...}
});
The cookie is not included in this request, and thus fails.
It turns out, setting SameSite=lax was doing the opposite of what I thought it would. Removing that solved this issue.
I have a login setup for one of my sites where the user types their information into a login popup on the home page, which then submits the information back to a servlet and then receives a response back via JSON. The home page then proceeds to send the user to their profile page or alternatively displays an error (e.g., if username and password do not match).
$.ajax({
dataType: 'jsonp',
async: false,
url: loginLocation,
type: 'GET',
crossDomain: true,
cache: false,
xhrFields: crossDomain ? {
withCredentials: true
} : {},
data: ({'key1': value1, 'key2': value2, ..., 'keyN':'valueN'}),
success: function(data){
if (data && data.status && data.status == "success") {
window.location = profileLocation;
} else {
errorHandler();
}
},
error: errorHandler
});
I am looking to change this from a GET request to a POST in order to prevent arbitrary query strings being sent into the servlet. However, it appears that there are several considerations at play here with regards to how the solution ought to be laid out. It must:
use POST instead of GET
be a cross-domain request (the login page and the servlet are on different domains over both of which I have access/control)
use the withCredentials parameter (the login functionality relies on the JSESSIONID cookie so this parameter is required)
be compatible with IE8 and above
I have tried looking into cross-domain ajax requests that fit the above criteria, but the major sticking point seems to be the IE8/IE9 compatibility. Approaches such as easyXDM appear to be ambiguous as to support for these browsers (I have seen conflicting reports online as to how it works in IE8) and I don't want to run into the danger of realizing it won't work halfway through implementation.
So in short, is there a way to do cross-domain ajax requests using POST and with the withCredentials parameter, that is also compatible with IE8+? Is easyXDM an appropriate solution to this?
I was able to determine the solution to the above question by using the xdomain library (found at https://github.com/jpillora/xdomain) which overrides the request behavior to allow cross-domain ajax in IE8 and IE9. This involved setting up the proxy.html as shown in the example on the xdomain site as well as adding Access-Control-Allow-Origin and other related headers to the server response. This allows cross-domain ajax JSON POST requests using withCredentials in IE8+ per the criteria listed in the original post. It also allows cross-domain requests between HTTP and HTTPS.
I'm making a chrome extension for a site which provides api to check if user is signed in or not. The api is for a GET request. So when i'm, not singed in it gives.
{ status: "ok", authenticated: false}
When i'm signed in it gives me
{status : "ok", authenticated: true, id: 123}
This works fine on browser, chrome extensions like Postman and advanced Rest Client. But when i use it in my chrome extension background it always says i'm not a authenticated user. I figured out that the ajax call i make does not send cookies for the domain, but the chrome extension like Postman or Advanced REST client do send cookies along with XHR request.
Any idea how can i make ajax to send cookies along with it.
here is my ajax call from chrome extension
$.ajax({
method:"GET",
// xhrFields: {
// withCredentials: true
// },
// crossDomain: true,
url:"http://test-staging.herokuapp.com/user/details",
success: function(result){
if(result.status=="ok"){
alert(JSON.stringify(result));
cb(result.authenticated);
}
},
error: function(err){
alert("unable to authenticate user "+JSON.stringify(err))
}
})
UPDATE 1:
I'm able to get the domain cookies details from the background script. Now i'm looking how i can send the cookies with the ajax call?
If the content script is injected into a page with an origin
(protocol, host and port combination) different from the API origin:
Cookies could be blocked by the third-party cookie blocking feature.
Check if it is enabled: chrome://settings/content/cookies.
Background scripts are not affected by it (as of Chrome 81).
Either set withCredentials: true (credentials: 'include' for fetch)
or add the origin into the permissions section of manifest.json.
To receive the response, correct CORS headers are required in either case.
Prefer moving API calls into a background script and passing data to the
content script with sendMessage to circumvent the third-party cookie blocking,
CORB and CORS restrictions. If you choose to do so, add the API origin into the
permissions section of manifest.json.
This is an old question, but what did it for me had to do with setting a couple flags on my cookies.
According to this blog post: https://www.gmass.co/blog/send-cookie-cross-origin-xmlhttprequest-chrome-extension/
You need to have the samesite: None flag set for this to work. This seems kind of obvious, but wasn't mentioned on most other resources for some reason. In addition, if you want samesite = None, you also need the Secure; flag on the set-cookie: response header so that Chrome will actually listen to it.
For me, and likely for you, this means messing around in your API to have those flags set correctly. For me it even meant I had to make HTTPS work on my localhost server I was developing on, so that chrome would trust me that the cookie was secure. In addition, you need credentials: 'include' as the earlier poster said.
For anyone using flask, this looked like:
app.config['SESSION_COOKIE_SAMESITE'] = "None"
app.config['SESSION_COOKIE_SECURE'] = True
plus debugging with Https (export FLASK_RUN_CERT=adhoc) on the command line.
This is a complex one that took me a long time, but the blog post linked above was a huge help.
I realize this question has been asked a dozen or more times and each response given indicates I am doing it right but perhaps I am missing something.
AJAX serves up CORS request like so...
$.ajax({
url: 'someotherdomain.com',
type: 'post',
data: {key: 'value'},
dataType: 'json',
async: false,
crossDomain: true,
beforeSend: function(xhr){
xhr.withCredentials = true;
},
success: function(x, status, xhr){
},
error: function(xhr, status, error){
}
});
PHP serves up CORS requests like so...
header('Access-Control-Max-Age: 1728000');
header('Access-Control-Allow-Origin: http://someotherdomain.com');
header('Access-Control-Allow-Methods: POST');
header('Access-Control-Allow-Headers: Content-MD5, X-Alt-Referer');
header('Access-Control-Allow-Credentials: true');
header("Content-Type: application/json; charset=utf-8");
According to all documentation as long as the 'Access-Control-Allow-Credentials' server side header, and the 'withCredentials=true' client side header is set session cookie handling between the domains should be transparent. Am I missing something?
async: false
was preventing the session cookie from being sent back to the server on each request. The following fixed it.
async: true
Although this does allow for the session cookie to get set by the browser when making a cross origin request sharing call, I am now experiencing problems regarding the following scenario:
Server A sends response to client
Client using CORS makes request of server B
XMLHttpRequest -> PHP -> Session handler -> MySQL -> Stored Procedure
Due to the MUTEX locks in the PHP session management the asynchronous nature and apparently, requirement may force a work around of manually setting the cookie with a different header option such as XCookie or something similar to keep the servers session and client requests synchronized.
This particular work around does not sit well with me as I believe it would open up an easy lane of travel for session hijacking and session replay attack vectors.
Using an SSL/TLS wrapped connection may assist in preventing the above scenario but in terms of independently providing security measures for the client I do not believe this should suffice.
Anyone with any thoughts on this?
In your example above, you are setting the Access-Control-Allow-Origin header to 'http://someotherdomain.com', which is the same as the url you are requesting from JQuery. The Access-Control-Allow-Origin header should be the value of the domain the request is coming from. As a quick, test, try setting the value of this header to '*' (without the quotes) and see if it works ('*' means all domains are allowed).