I want to accept only limit domain requests such as i want to accept all request which comes from www.abc.com and www.xyz.com all other request should be denied . I can't be use token process from server side because multiple domain using my javascript code so here we can't think about server side token and HTTP_ADDR can be manipulate from javascript. Please suggest how to validate it which is reliable?
XMLHttpRequest will insert an Origin header into the request which tells you the site that the request came from.
Use that to populate the Access-Control-Allow-Origin header.
(This, obviously, provides no protection against non-Ajax requests).
It appears that you are trying to prevent Cross Site Request Forgery (CSRF) rather than preventing actors from creating arbitrary cURL requests to your site in order to retrieve data. For this purpose, I recommend the following approach.
For "safe" methods you could check that the Origin header matches your whitelist, and if so you output the Access-Control-Allow-Origin header to match. This is an implementation of CORS.
For "unsafe" methods you could set and check a header such as X-Requested-With is present. It is harder to secure unsafe methods using Origin because old browsers do not send the header, and some new browsers do not send the header for same origin requests.
The above approach only works for AJAX, and not for normal form GET or POSTs or cross domain resource requests.
Related
So I have been developing a webpage the would give random quotes whenever a user clicks on a button by calling an API.
Please refer to my previous question for more information Not able to get values (quotes) from the API using jquery
I was told that the reason I couldn't get the response from the API is because my ACAS(Access-control-Allow-Origin) is not set properly in my server and I have to debug it.
Now that I don't much about ACAS or CORS. I have some questions. SO here they are:
1. What exactly is ACAS and how is it related to CORS?
2. How do I debug my page and set the ACAS?
3. Does that have to do anything with my jQuery? Or should I configure only my browser.
You can find many documents on the internet
,so I'll just briefly talk about CORS.
When you're sending request to different domain
for example from a.com to b.com, or localhost:8080 to a.com......
your're making a cross-origin HTTP request ,
sometime this is not allowed, for example Ajax (as you're doing) requests.
Because XhttpRequest, Fetch (both are Ajax API) follow same-origin policy, which means by default you can only make requests form the same domain, ex: from site.com to site.com/users.
The reason they follow the same-origin policy is to prevent CSRF attack (Cross-site request forgery).
1.So basically you cannot get the result of cross site Ajax request, it will block by browser because of the security issue, unless the response header Access-control-Allow-Origin is set to allow client's site to send cross site ajax request. ex: Access-control-Allow-Origin:*allow all sites form different domain; Access-control-Allow-Origin:www.b.comonly allow www.b.com domain.
2.Take Chrome for example If the cross site request's result is blocked, it will show on browser's console:
You need to set the response header in your server, for example I set Access-control-Allow-Origin:*, then in browser's "network" console you can see the header is set, and now I can get the Ajax result.
I think nothing should do at client side, all is at server side.
Refer to this post as it makes this clear
Note also that there are some techniques frequently used in order to bypass CORS like setting up a proxy which acts as a relay for your request or using JSONP instead of JSON.
I am trying to understand why CORS is working in way that it works.
As I learned from this post, when page from www.a.com makes AJAX request to www.b.com, then it's the www.b.com that decides if request should be allowed or not.
But what is exactly secured on client in such model?
For example, if a hacker succeeds to make an XSS script injection to my page, then it makes an AJAX request to his domain to store user data. So a hacker's domain will allow such a request for sure.
I thought that www.a.com should decide to which domains to allow the request to. So in theory within a header Access-Control-Allow-Origin I would like to put the whole list of the domains that are allowed for AJAX CORS requests.
Can someone explain what security problems the current CORS implementation handles?
As I learned from this post, when page from www.a.com makes AJAX request to www.b.com, then it's the www.b.com that decides if request should be allowed or not.
Not quite. The request isn't blocked (at least, if it is simple).
By default the JavaScript running on www.a.com is forbidden access to the response from www.b.com.
CORS provides a means by which www.b.com can give permission to the JavaScript on www.a.com to access the response.
But what is exactly secured on client in such model?
It stops the author of www.a.com from reading data from www.b.com using the browser of a User who has visited both sites and has been authenticated on www.b.com (and thus has access to data that isn't public).
For example, Alice is logged into Google. Alice visits malicious.example which uses XMLHttpRequest to access data from gmail.com. Alice has a GMail account so the response has a list of the most recent email in her inbox. The same origin policy prevents malicious.example from reading it.
For example, hacker success to make XSS script injection to my page, then it makes AJAX request to his domain to store user data. So hackers domain will allow such request for sure.
Correct. XSS is a different security problem that needs to be addressed at source (i.e. at www.a.com and not in the browser).
In addition to #Quentin's excellent answer, there is another technology known as Content Security Policy which describes what you are after.
I thought that www.a.com should decide to which domains to allow the request to. So in theory within a header Access-Control-Allow-Origin I would like to put the whole list of the domains that are allowed for AJAX CORS requests.
With CSP, you could set a header from your domain (www.a.com in your example) to restrict AJAX requests:
connect-src limits the origins to which you can connect (via XHR, WebSockets, and EventSource).
So to use this you can add this Content-Security-Policy HTTP header to your HTML response:
Content-Security-Policy: connect-src 'self'
This will restrict AJAX requests to www.a.com if that header is in the response from www.a.com:
'self' matches the current origin, but not its subdomains
See here for supported browsers.
I have read some articles on Same Origin Policy and CORS and still doesn't understand well the security that it brings to the user.
The Same Origin Policy gives a true valuable security, preventing a site from an origin from accessing some webpage content on another website. Thus preventing the threat of having the content of a iframe accessed by the script of the container, possibly faked/phishing website.
But here comes AJAX and CORS. CORS gives the ability for the server to control which origins can access it. But, at the end, it is the browser which stops the request if not allowed, after headers handcheck.
So, imagine you get some malicious website myphishing.com. You want to show information from another trusted website mybank.com through AJAX request to this site. This one is protected by well configured CORS headers only allowing request from mybank.com origin. What if, me author of myphising.com, relay all requests to mybank.com by a proxy that alter headers in both request and response way to fake client browser and bank server? It seems one can change the origin header in the request for a mybank.com one, and change the CORS response headers to make the browser think myphishing.com is allowed to make the request. Headers handcheck passed, you can then send the request and get the response with similar headers substitution tricks.
Perhaps I'm totally misleaded, but I would be very pleased if someone could show me where I have misunderstand the whole thing.
Possible duplicate but I didn't find my answer here: What is the threat model for the same origin policy?.
What if, me author of myphising.com, relay all requests to mybank.com by a proxy that alter headers in both request and response way to fake client browser and bank server?
You could do that anyway, CORS or no CORS.
If the request is coming from your proxy, however, then it has no way to know what credentials the browser would have sent to the server if the request was coming from the browser.
I am trying to understand why CORS is working in way that it works.
As I learned from this post, when page from www.a.com makes AJAX request to www.b.com, then it's the www.b.com that decides if request should be allowed or not.
But what is exactly secured on client in such model?
For example, if a hacker succeeds to make an XSS script injection to my page, then it makes an AJAX request to his domain to store user data. So a hacker's domain will allow such a request for sure.
I thought that www.a.com should decide to which domains to allow the request to. So in theory within a header Access-Control-Allow-Origin I would like to put the whole list of the domains that are allowed for AJAX CORS requests.
Can someone explain what security problems the current CORS implementation handles?
As I learned from this post, when page from www.a.com makes AJAX request to www.b.com, then it's the www.b.com that decides if request should be allowed or not.
Not quite. The request isn't blocked (at least, if it is simple).
By default the JavaScript running on www.a.com is forbidden access to the response from www.b.com.
CORS provides a means by which www.b.com can give permission to the JavaScript on www.a.com to access the response.
But what is exactly secured on client in such model?
It stops the author of www.a.com from reading data from www.b.com using the browser of a User who has visited both sites and has been authenticated on www.b.com (and thus has access to data that isn't public).
For example, Alice is logged into Google. Alice visits malicious.example which uses XMLHttpRequest to access data from gmail.com. Alice has a GMail account so the response has a list of the most recent email in her inbox. The same origin policy prevents malicious.example from reading it.
For example, hacker success to make XSS script injection to my page, then it makes AJAX request to his domain to store user data. So hackers domain will allow such request for sure.
Correct. XSS is a different security problem that needs to be addressed at source (i.e. at www.a.com and not in the browser).
In addition to #Quentin's excellent answer, there is another technology known as Content Security Policy which describes what you are after.
I thought that www.a.com should decide to which domains to allow the request to. So in theory within a header Access-Control-Allow-Origin I would like to put the whole list of the domains that are allowed for AJAX CORS requests.
With CSP, you could set a header from your domain (www.a.com in your example) to restrict AJAX requests:
connect-src limits the origins to which you can connect (via XHR, WebSockets, and EventSource).
So to use this you can add this Content-Security-Policy HTTP header to your HTML response:
Content-Security-Policy: connect-src 'self'
This will restrict AJAX requests to www.a.com if that header is in the response from www.a.com:
'self' matches the current origin, but not its subdomains
See here for supported browsers.
I've read that setting document.domain = "example.com" lets me access the parent domain from a subdomain.
Will the same work the other way around?
Let's say my main site is running under http://example.com. All API functions that I want to access via AJAX (GET & POST) are hosted on http://api.example.com.
Will I be able to access api.example.com from example.com?
EDIT: Looking at document.domain again, I don't think that this will solve the problem. The result from calls to api.example.com are not necessary HTML, but output from a PHP script running on the API server. It can be JSON, plain text, etc. so there's no way to set document.domain for that (since it's not an iframe).
You need to set document.domain on BOTH pages
Alternatively set CORS headers on your server:
http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/
A Quick Overview of CORS
Firefox 3.5 and Safari 4 implement the
CORS specification, using
XMLHttpRequest as an “API container”
that sends and receives the
appropriate headers on behalf of the
web developer, thus allowing
cross-site requests. IE8 implements
part of the CORS specification, using
XDomainRequest as a similar “API
container” for CORS, enabling simple
cross-site GET and POST requests.
Notably, these browsers send the
ORIGIN header, which provides the
scheme (http:// or https://) and the
domain of the page that is making the
cross-site request. Server developers
have to ensure that they send the
right headers back, notably the
Access-Control-Allow-Origin header for
the ORIGIN in question (or ” * ” for
all domains, if the resource is
public) .
The CORS standard works by adding new
HTTP headers that allow servers to
serve resources to permitted origin
domains. Browsers support these
headers and enforce the restrictions
they establish. Additionally, for HTTP
request methods that can cause
side-effects on user data (in
particular, for HTTP methods other
than GET, or for POST usage with
certain MIME types), the specification
mandates that browsers “preflight” the
request, soliciting supported methods
from the server with an HTTP OPTIONS
request header, and then, upon
“approval” from the server, sending
the actual request with the actual
HTTP request method. Servers can also
notify clients whether “credentials”
(including Cookies and HTTP
Authentication data) should be sent
with requests.