Minio: CORS header is based on the wrong request field

Created on 5 Jul 2017  Â·  5Comments  Â·  Source: minio/minio

The Access-Control-Allow-Origin header is dynamically based on the Origin: request field. That opens the door for some quite serious security issues.

Expected Behavior

  1. Send request with Origin: www.evil.com
  2. in the response is the Access-Control-Allow-Origin NOT www.evil.com

Current Behavior

  1. Send request with Origin: www.evil.com
  2. the Access-Control-Allow-Origin header field in the response is www.evil.com

Possible Solution

You can make the Access-Control-Allow-Origin header configurable or use a whitelist for valid origins.

Steps to Reproduce (for bugs)

see above

Context

We want a secure infrastructure. If the header is Access-Control-Allow-Origin: www.evil.com, this permits the listed origin (domain) to make visitors’ web browsers issue cross-domain requests to the server and read the responses - something the Same Origin Policy would normally prevent.
More to read: http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html

Your Environment

medium working as intended

Most helpful comment

I encountered the same problems and found the way. If you have proxy Nginx, you can just hide the Minio headers like:

        proxy_hide_header 'access-control-allow-origin';
        proxy_hide_header 'access-control-expose-headers';
        proxy_hide_header 'access-control-allow-credentials';

And then add yours, like:

        if ($http_origin) {
            add_header Access-Control-Allow-Credentials  true;
            add_header Access-Control-Allow-Methods      "GET, POST, OPTIONS";
            add_header Access-Control-Allow-Origin       $http_origin;
        }

All 5 comments

@Peter-Prochaska Minio does not use browser Cookies for authentication, instead uses Authorization header for authentication.

Minio serves 3 types of requests:

  • S3 requests: authenticated using signature V4 authentication
  • Minio admin calls: authenticated using signature V4 authentication
  • Minio-Browser Web-RPC calls: authenticated using JSON Web Tokens

None of the APIs are vulnerable to CSRF attacks. Hence protection is not needed for cross-origin requests.

In almost all minio deployments, Minio storage will be on one domain and web-server will be on different domain. Taking your example, web-server is on www.owncloud.com and Minio is on storage.marketplace.owncloud.com. Hence we allow cross origin requests by default. Let us know if we are missing anything.

@krishnasrinivas You didn't get the point. Allow cross origin requests is ok, but the Access-Control-Allow-Origin header in the response depends on the Origin header from the request. This Origin header is from userspace and can be changed to anything an attacker wants.

@Peter-Prochaska yes the attacker can change the Origin header can be anything the attacker wants, I explained how it is not a security issue with Minio server as we do not use Cookies for authentication.

@Peter-Prochaska please re-open the issue if you think we are missing anything.

@deekoder shall we close this one?

I encountered the same problems and found the way. If you have proxy Nginx, you can just hide the Minio headers like:

        proxy_hide_header 'access-control-allow-origin';
        proxy_hide_header 'access-control-expose-headers';
        proxy_hide_header 'access-control-allow-credentials';

And then add yours, like:

        if ($http_origin) {
            add_header Access-Control-Allow-Credentials  true;
            add_header Access-Control-Allow-Methods      "GET, POST, OPTIONS";
            add_header Access-Control-Allow-Origin       $http_origin;
        }

Was this page helpful?
0 / 5 - 0 ratings