I have an issue where I executing an AJAX request. Instead of seeing the normal POST or GET preceeding the action page url, I see OPTIONS. The data is successfully posted, but there is no response from the action page. What does OPTIONS indicate?
"The OPTIONS method represents a
request for information about the
communication options available on the
request/response chain identified by
the Request-URI. This method allows
the client to determine the options
and/or requirements associated with a
resource, or the capabilities of a
server, without implying a resource
action or initiating a resource
retrieval."
source
This is due to a cross-domain AJAX attempt. Sometimes something as harmless-looking as requesting h ttp://www.example.com from h ttp://example.com can cause unexpected behavior.
Related
For about two weeks, customers complain that our site is broken. After debugging and asking customers for screenshots of the error, we found out that Kaspersky Internet Security blocks AJAX requests, necessary for the site to work.
Console writes this error:
TypeError: ns.GetCommandSrc is not a function
What makes Kaspersky block certain requests?
Our site is on www.mysite.example and makes requests to api.mysite.example. access-allow-origin headers are set and work for us and most of the other customers.
I found that in KAV Settings/Additional/Network, there is an "Inject script into web traffic to interact with web pages" option.
Try turning that off to see if stops the problem.
I have the same issue. The block is intermittent. It looks to me that KAV tries to get some info from its servers to deal with the request, and if that fails, it breaks the AJAX call.
Luckily for me, I have a fallback action, providing default information to the app when the AJAX fails.
In another thread someone suggested that the issue is with the URL or parameters of the call. If it has keywords that can indicate a sensitive operation (banking and such), KAV gives it some extra attention. In my case the call has "license" in the URL, so it may be a correct guess. I'm planning to change the URL to something unremarkable, but it will take some time.
After the most recent Firefox update (68.0), I am having problems with persistent session data.
When a user logs in, as the page loads, there are various expected CSP violations that send a POST request containing the violation report to the path report-uri directive contains.
Subsequent API GET requests to retrieve user data returns a 403 Forbidden, which (by design) redirects the user back to the login page. Since the user is logged in already, same API requests are sent that result in another 403, which leads to an infinite loop until after an arbitrary number of loops API requests return 200 OK.
All requests (both POST and GET) before and after the update are the same.
It seems to me that the fact that there are CSP report POST requests before the API requests changes something related to the session, which is used by the back-end to determine if the user has the correct privileges.
Could Firefox have changed something about the way it handles CSP report-uri requests or their responses change with the update?
What would be a good way to approach this problem?
Firefox has just been updated to version 68.0.1. The update seems to have fixed this problem. Release notes don't seem to be related to this in a way I can make sense, but regardless, the problem is solved.
Am facing an issue, where two calls are getting registered in network tab (PFA)
These two calls have same request and responses.
Actually there is one call only made from client side. Need to understand why this second call getting registered.
FYI : This is sitecore based project. window.location.href is used in JS side.
Please provide insights for this problem.
Whenever a cross-origin request is made, two requests are send, instead of one by chrome:
1. The first one is option type. It checks whether the origin is allowed or not.
2. The second one is your actual request.
For more information, have a look on answers here: AJAX in Chrome sending OPTIONS instead of GET/POST/PUT/DELETE?
From the screenshot, it seems that there are 2 different Initiators calling the same resource. You have 1 AJAX call (xhr) and the other one is Document which might be in the page itself or another JS.
I am newbie to website security and currently trying to understand Same-Origin-Policy in some depth.
While there are very good posts on stackoverflow and elsewhere about the concept of SOP, I could not find updated information on whether chrome and other browsers allow cross-domain XHR post requests to be 'sent' from the first place.
From this 5 year old post, it appears that chrome allows the request to pass through to the requested server but does not allow reading the response by the requester.
I tested that on my website trying to change user info on my server from a different domain. Details below:
My domain: "www.mysite.com"
Attacker domain: "www.attacker.mysite.com"
According to Same-Origin-Policy those two are considered different Origins.
User (while logged in to www.mysite.com) opens www.attacker.mysite.com and presses a button that fires a POST request to 'www.mysite.com' server...The submitted hidden form (without tokens in this case) has all the required information to change the user's info on 'www.mysite.com' server --> Result: CSRF successful attack: The user info does indeed change.
Now do the same but with javascript submitting the form through JQuery .post instead of submitting the form--> Result: Besides chrome giving the normal response:
No 'Access-Control-Allow-Origin' header is present on the requested
resource
, I found that no change is done on the server side...It seems that the request does not even pass through from the browser. The user info does not change at all! While that sounds good, I was expecting the opposite.
According to my understanding and the post linked above, for cross-domain requests, only the server response should be blocked by the browser not sending the post request to the server from the first place.
Also, I do not have any CORS configuration set; no Access-Control-Allow-Origin headers are sent. But even if I had that set, that should apply only on 'reading' the server response not actually sending the request...right?
I thought of preflights, where a request is sent to check if it's allowed on the server or not, and thus blocking the request before sending its actual data to change the user info. However, according to Access_Control_CORS , those preflights are only sent in specific situations which do not apply to my simple AJAX post request (which includes a simple form with enctype by default application/x-www-form-urlencoded and no custom headers are sent).
So is it that chrome has changed its security specs to prevent the post request to a cross domain from the first place?
or am I missing something here in my understanding to the same-origin-policy?
Either way, it would be helpful to know if there is a source for updated security measures implemented in different web browsers.
The XMLHttpRequest object behavior has been revisited with time.
The first AJAX request were unconstrained.
When SOP was introduced the XMLHttpRequest was updated to restrict every cross-origin request
If the origin of url is not same origin with the XMLHttpRequest origin the user agent should raise a SECURITY_ERR exception and terminate these steps.
From XMLHttpRequest Level 1, open method
The idea was that an AJAX request that couldn't read the response was useless and probably malicious, so they were forbidden.
So in general a cross-origin AJAX call would never make it to the server.
This API is now called XMLHttpRequest Level 1.
It turned out that SOP was in general too strict, before CORS was developed, Microsoft started to supply (and tried to standardize) a new XMLHttpRequest2 API that would allow only some specific requests, stripped by any cookie and most headers.
The standardization failed and was merged back into the XMLHttpRequest API after the advent of CORS. The behavior of Microsoft API was mostly retained but more complex (read: potentially dangerous) requests were allowed upon specific allowance from the server (through the use of pre-flights).
A POST request with non simple headers or Content-Type is considered complex, so it requires a pre-flight.
Pre-flights are done with the OPTIONS method and doesn't contain any form information, as such no updates on the server are done.
When the pre-flight fails, the user-agent (the browser) terminate the AJAX request, preserving the XMLHttpRequest Level 1 behavior.
So in short: For XMLHttpRequest the SOP was stronger, deny any cross-origin operations despite the goals stated by the SOP principles. This was possible because at the time that didn't break anything.
CORS loosened the policy allowing "non harmful" requests by default and allowing the negotiation of the others.
OK...I got it...It's neither a new policy in chrome nor missing something in SOP...
The session cookies of "www.mysite.com" were set to "HttpOnly" which means, as mentioned here, that they won't be sent along with AJAX requests, and thus the server won't change the user's details in point (4).
Once I added xhrFields: { withCredentials:true } to my post request, I was able to change the user's information in a cross-domain XHR POST call as expected.
Although this proves the already known fact that the browser actually sends the cross-domain post requests to the server and only blocks the server response, it might still be helpful to those trying to deepen their understanding to SOP and/or playing with CORS.
I have an issue with a Facebook Page Tab I have built.
The website functions perfectly fine in Chrome and Firefox but I have an issue when I try to do something simple in IE.
[BASE URL: http://domain.com/]
[REQ URL: http://domain.com/request]
What I am trying to do is make a simple ajax request from my server BASE URL to my server again on REQ URL, In Chrome or Firefox I get the expected result, IE however I get a couple of errors and warnings.
Warnings are as follows (without sensitive domain information)
SEC7118: XMLHttpRequest for https://www.facebook.com/dialog/oauth?client_id=APP_ID&redirect_uri=URL_ENCODED_REDIRECT_URI required Cross Origin Resource Sharing (CORS).
SEC7119: XMLHttpRequest for https://www.facebook.com/dialog/oauth?client_id=APP_ID&redirect_uri=URL_ENCODED_REDIRECT_URI required CORS preflight.
Errors are as follows
SEC7120: Origin http://domain.com not found in Access-Control-Allow-Origin header.
SCRIPT7002: XMLHttpRequest: Network Error 0x80070005, Access is denied.
I have done a lot of research on these errors and I know that they are related to Cross Origin Control and making requests from one domain that does not match another. The strange thing is though that both my domains are the same so CORS should not apply. I can't figure out what I'm missing. I have read at least 20 articles on stack overflow with none of them able to address my problem exactly.
The /request/ in the REQ_URL is a method that gets called from a controller, all I need is for this method to be called there is nothing special about it, it's a simple PHP function.
function request() {
return 'you win!';
}
The ajax is using jQuery to make the request specificly the $.get method this is my code:
$.get('/request', function(response){
console.log(response);
});
I get no response.
I have also tried this with $.ajax and calling the complete method I get a text status type returned of 'error' I expect this to be the result of the error above.
I have read and understand the articles as follows:
Cross-origin resource sharing
Same-origin policy
According to the Same-origin policy I shouldn't be bound to CORS and my get request should just work or am I missing something.
Any help is appreciated.
['UPDATE']
I have identified that the above errors occur only when inside facebook (Facebook Page Tab) this "I think" is a result of the iframe being from the domain "http://static.ak.facebook.com/" and my domain "http://domain.com" This breaks the Same-origin policy rule. Very annoying because when the ajax calls are made they are sent from "http://static.ak.facebook.com/" to "http://domain.com" there in I am getting Cross-origin policy errors.
I still don't know how to fix this problem.
Not many up votes, Not many views.
I found the issue, and the solution.
For my particular case I was using sessions to handle information on the server side, what was happening was the session was not persisting in IE witch was causing some of my other code to redirect he ajax request to another domain (facebook.com) resulting in the cross domain request error you see above.
The Solution:
I found out that IE doesn't like to pass sessions around through ajax but you can tell it that it would be a good idea do follow suit to the other modern browsers and that was as simple as adding a P3P header.
Add this to your code before sending a request and the session variables should be sent in the requests.
header('P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
I ended up rewriting my application without so many dependicies on the sessions but this was definatly a good learning point about IE and how it handels sessions through ajax.