CORS (Cross-origin resource sharing) is supported by most browsers to hand cross origin requests. Basically, when html content is loaded from bar.com, and it sends an xmlhttprequest to foo.com, then when foo.com returns the response to the browser, it needs to specify the header of
Access-Control-Allow-Origin: *
or
Access-Control-Allow-Origin: http://bar.com
otherwise, the browser will not load the response to the web content. So in this case browser enforces the check based on the server's response header.
Note CORS does not care how the script is loaded in original html page (bar.com), the browser only makes the decision after the response of cross domain request comes back. It would be better it browser can proactively disable the malicious js code if it is not from trusted source. That is how Content-Security-Policy does.
How Content-Security-Policy works is when the original html page returned from bar.com, the server can specify the trusted source for any javascript, css, so that even if malicious js code gets loaded in the page, it will not be executed. For example, if the policy indicates
script-src 'self'
then only the script from the same domain can be executed. Note this also disable JSONP function when it is used for cross domain request, as the script is loaded from a different domain, and it will not be trusted unless Content-Security-Policy allows it to do so.
By the way, for CORS request, by default, hte browser does not send credentials (cookies and http authentication scheme) with the request. In order to send them with a cross-origin request, the client must set XMLHttpRequest.withCredentials to true. In addition, the server must include Access-Control-Allow-Credentials header, this header tells the browser that the server allows the credential to be used for a cross origin request. If the browser sends the credentials with the request, but the server response does not include a valid Access-Control-Allow-Credential header, then browser will not expose the response to the application, and the ajax request will fail.
Access-Control-Allow-Origin: *
or
Access-Control-Allow-Origin: http://bar.com
otherwise, the browser will not load the response to the web content. So in this case browser enforces the check based on the server's response header.
Note CORS does not care how the script is loaded in original html page (bar.com), the browser only makes the decision after the response of cross domain request comes back. It would be better it browser can proactively disable the malicious js code if it is not from trusted source. That is how Content-Security-Policy does.
How Content-Security-Policy works is when the original html page returned from bar.com, the server can specify the trusted source for any javascript, css, so that even if malicious js code gets loaded in the page, it will not be executed. For example, if the policy indicates
script-src 'self'
then only the script from the same domain can be executed. Note this also disable JSONP function when it is used for cross domain request, as the script is loaded from a different domain, and it will not be trusted unless Content-Security-Policy allows it to do so.
By the way, for CORS request, by default, hte browser does not send credentials (cookies and http authentication scheme) with the request. In order to send them with a cross-origin request, the client must set XMLHttpRequest.withCredentials to true. In addition, the server must include Access-Control-Allow-Credentials header, this header tells the browser that the server allows the credential to be used for a cross origin request. If the browser sends the credentials with the request, but the server response does not include a valid Access-Control-Allow-Credential header, then browser will not expose the response to the application, and the ajax request will fail.
No comments:
Post a Comment