Is this CORS handler safe?

Question

I wrote this trivial method to handle CORS in a simple server proxy of mine.

private void handleCors(HttpServletRequest req, HttpServletResponse resp) {
  final String origin = req.getHeader("Origin");
  if (Strings.isNullOrEmpty(origin)) {
    return;
  }
  if (!origin.startsWith("http://localhost:")) {
    return;
  }
  resp.setHeader("Access-Control-Allow-Origin", origin);
  resp.setHeader("Access-Control-Allow-Credentials", "true");
  resp.setHeader("Access-Control-Expose-Headers", "Authorization");
  resp.setHeader("Access-Control-Allow-Headers", "Authorization, Content-Type");
}

It's not needed for the real application, it's only used when testing manually (with ionic serve). I guess, it is safe because of doing nothing except when the origin is localhost, but better safe than sorry.

Moreover, findbugs complains about response splitting vulnerability. Should I simply use URLEncoder.html#encode or is there more to it?

Would in general removing spaces or adding no CORS headers in case of contained spaces do?

Answer 1

CORS is safer and more flexible than earlier techniques such as JSONP.

WebAPI works great straight out of the box for GET requests. However, once you start using it for POST, PUT or DELETE operations, then CORS kicks in and drops requests from hitting the server. CORS stops any cross domain requests so if your api is running at www.myapi.com and a request from www.mywebsite.com comes in, the request will be dropped. This is a security feature to ensure that requests from unknown domains cannot hit the server.

If you are using a web client to execute ajax calls, then there is one more thing you need to add to your ajax call to ensure that CORS words on all browsers.

$.support.cors = true
crossDomain: true

Resource Link:

How to Implement Cross Domain Requests (CORS) in WebAPI, old school?

But in a single line, if we want to say then CORS handler is not safe. Already @zapl has given info about this.

Now I am trying to give you some attack type with some scenerios. Hope it will give you clear information.

CORS (In)security?

1. Several security issues arise from the improper implementation of CORS, most commonly using a universal allow notation (*) in the server headers.
2. Clients should not trust the received content completely and eval or render content without sanitization which could result in misplaced trust.
3. The application that allows CORS may become vulnerable to CSRF attacks.
4. Prolonged caching of Preflight responses could lead to attacks arising out of abuse of the Preflight Client Cache.
5. Access control decisions based on the Origin header could result in vulnerabilities as this can be spoofed by an attacker.

CORS Security - Universal Allow

• Setting the 'Access-Control-Allow-Origin' header to *
• Effectively turns the content into a public resource, allowing access from any domain.

Scenarios:

• An attacker can steal data from an intranet site that has set this header to * by enticing a user to visit an attacker controlled site
  on the Internet.

• An attacker can perform attacks on other remote apps via a victim’s browser when the victim navigates to an attacker controlled site.

---

CORS Security – Misplaced Trust

1. Data exchange between two domains is based on trust
2. If one of the servers involved in the exchange of data is compromised then the model of CORS is put at risk

Scenarios:

• An attacker can compromise site A and host malicious content knowing site B trusts the data that site A sends to site B via CORS request resulting in XSS and other attacks.
• An attacker can compromise site B and use the exposed CORS functionality in site A to attack users in site A.

CSRF with CORS

1. Server may process client request to change server side data while verifying that the Origin header was set
2. An attacker can use the .withCredentials = “true” property of XHR to replay any cookies to the application on which the victim is logged in

Scenarios:

• An attacker sets the Origin header or uses a trusted site A to send a non idempotent request to site B.
• The victim who is logged into site B when he is viewing the trusted site A causes site B to create a user account without his knowledge
  via a CSRF attack.

CORS – Caching of Preflight responses

1. The Access-Control-Max-Age header is set to a high value, allowing browsers to cache Preflight responses.
2. Caching the preflight response for longer duration can pose a security risk.
3. If the COR access-control policy is changed on the server the browser would still follow the old policy available in the Preflight Result Cache.

CORS – Access Control based on Origin

1. The Origin header indicates that the request is from a particular domain, but does not guarantee it.
2. Spoofing the Origin header allows access to the page if access is based on this header

Scenarios:

• An attacker sets the Origin header to view sensitive information that is restricted
• Attacker uses cURL to set a custom origin header:

     curl --header 'origin:http://someserver.com' http://myserver.com:90/demo/origin_spoof.php

Here is an example is given. You can go through this link :

1. https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)
2. Some Security Impacts of HTML5 CORS or How to use a Browser as a Proxy