When I was trying to log, I got a Cross-Origin Error. Below is the complete error message.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://10.138.31.41:8243/insurance/1.0.0/i_customers/q?{%22username%22:%22q%22}. This can be fixed by moving the resource to the same domain or enabling CORS.
When your request is not sent from the same origin, browsers will send an options-request to the target server to make sure, whether the target server allows requests from the foreign origin with given http-method and headers for the requested endpoint.
It seems like the target server blocks your requests, so you should make sure, that the cors-response from your target server is adjusted (meaning it includes an "Access-Control-Allow-Origin"-Header listing the url your request comes from) or not rejected (maybe your request gets rejected, because you are requesting via https but ip-based, to the certificate is not accepted). If this is not possible, you could "bypass" the Same-Origin-Policy-Check from your browser with a jsonp-request (only http-get) or by sending the request over a reverse-proxy.
Related
Note: My site is in production mode, not testing. It is pending verification due to me adding an icon. This issue persisted before the verification was started.
Whenever my browser makes a request to Google for the one-tap widget or the pill, both requests return 400 Bad Request with an empty HTML page and the console is sent a message stating "The given origin is not allowed for the given client ID." I've gone onto the Google Cloud Console and checked my origins. I have only one listed, and it's the exact site I'm sending requests from my browser. My site also has its traffic proxied through Cloudflare if that makes a difference. In addition, I am using JavaScript callbacks (which work when used in PI#1).
Potential issue #1: The URLs are typed in wrong
When I insert localhost (I add https and http because I test with a HTTPS webserver locally using a Cloudflare origin certificate), the requests go through perfectly. However, the moment the requests are from my browser when it's not localhost, the requests fail. I've copied and pasted straight from the URL bar just to make sure that there's no typos or anything but the same results return.
Potential issue #2: The widget is making bad requests
I do open the URLs in other tabs (Which yield the same results from PI#1) and insert bogus URLs like example.com and thisisnotaurl.com to ensure it's not just dropping every request. Those requests return 403 Forbidden instead of 400 Bad Request.
Potential issue #3: The issue is browser specific
I've checked this issue on both Firefox and Microsoft Edge, both on the stable branches and completely up to date. I've disabled my ad block (UBlock Origin & Firefox built-in protection) to ensure they aren't messing with requests but everything except the crucial requests fail with 400 Bad Request. I have yet to test other browsers as I do not have them installed but I assume the same results come from them.
An example of the code can be found here: https://gist.github.com/Coder-Tavi/772ea25b16f3fa0b6b0e04739a1689dd.
The origins shown below are the exact website I am accessing. In addition, I've verified the client IDs are exactly the same as the ones I have added
Referrer Policy is improperly configured
The HTTP header Referrer-Policy controls the exact amount of data sent to servers regarding the origin of the request. In most cases, this is set to same-origin which means that the Referer header will send the origin to servers with the same origin.
Consider you have a webserver at example.com and another at web.example.com with a Referrer-Policy of same-origin. When example.com sends a request to web.example.com, the Referer header will contain the origin of the request, since it is the same origin. However, if example.com sends a request to google.com, the Referer header will not send any origin data, as google.com and example.com are not the same origin.
If we look at the requests, this directive is what we see
As such, we need to update the directive to allow the browser to send the origin in the Referer header. This can be done by inserting the following into the HTML of the current page.
<meta name="referrer" content="origin">
This meta tag will allow the browser to send the origin only to other webservers, and as such, Google will see the origin.
Consider the example above again. This time, when example.com sends a request to google.com, the request will contain a Referer header with the origin, as the directive allows for sharing of the origin. However, with this current policy, only the origin is sent, not the query parameters and other parts of the URL. With the following URL: https://example.com/test/123, google.com will only see https://example.com. The MDN Web Docs contain all the possible values and their effects.
I was trying to use my api and I have a function on ember app to login but when the login action is trigerred I receive a message below. What is the reason I am receiving this error?
login:1 Access to fetch at 'https://app-dev.some-url.com.au/api/login' from origin
'http://localhost:4099' has been blocked by CORS policy: Response to preflight request doesn't
pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested
resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch
the resource with CORS disabled.
Your API server isn’t configured to accept requests that come from a web application on another origin. Some options:
Configure your API to serve the Access-Control-Allow-Origin header
on the OPTIONS request that the browser makes to test this. It
could be Access-Control-Allow-Origin: * if you’re lazy or can’t
know in advance what origins people will be coming from. It’s hard
to be more specific about this without knowing details of your API.
Use Ember CLI’s API
proxying
feature to bypass the need for CORS. This is for development mode
only, though. You’d need a similar solution in production where
Ember CLI’s development server isn’t present.
I've created an API with C++ and the following library: https://github.com/yhirose/cpp-httplib
In the API I've added a header to responses for CORS:
svr.Post("/suggest", [&dr](const Request &req, Response &res){
res.set_header("Access-Control-Allow-Origin","(origin here)");
(origin here) is the origin of the server making the request.
On the browser side I've also enabled an extension to bypass CORS. But when trying to make an AJAX request to the API, I still get this error in my browser console:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://192.168.1.10:10120/suggest. (Reason: CORS request did not succeed).
The AJAX request is done through a script written in the Tampermonkey extension to work on a specific website.
Do I need to modify headers on the server hosting the website? Have I done something wrong on the C++ side?
Also it might be important to mention that the code worked before. All I did was come back to it another day with a different local IP address (which i reprogrammed into the c++ API)
I tried it again to answer #sideshowbarker and it gave me a new error about self signed certificates. After adding the exception it worked.
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.)
Building the app and running on the iPhone device gives the following errors:
I managed to get the details of the request sent from iOS Device, please check the below image is the request is valid or we need to do change something related to sending requests because there is no other place we can make any changes except the way we are sending requests
Header sending in the request is showing here:
To enable cross-origin requests, the server that is responding to the request needs to set headers that will tell the requesting browser (which is on a different domain) that it is allowed to load the resource from the different domain. Essentially, on the server (localhost) you will need add the headers to essentially white-list the calling domain as one that is allowed to fetch resources cross domain.
This is a useful article to help you ramp: https://www.html5rocks.com/en/tutorials/cors/
Also see http://excellencenodejsblog.com/handing-cors-for-your-mobile-app/