apiserver: CORS only works in insecure mode?

[xinzhangcmu]

I am writing a client-side AngularJS app that uses XMLHttpRequest trying to talk to the apiserver. The apiserver was brought up with the following flags, especially with cors-allowed-origins hoping to allow CORS.

--cors-allowed-origins=.* 
--insecure-bind-address=127.0.0.1 
--insecure-port=8080 
--bind-address=0.0.0.0 
--secure-port=443

and I configured apiserver to support basic auth with https.

However, the pre-flight OPTIONS request failed with 401. Below is my rationale:

• For CORS to work, the client will always first send a pre-flight OPTIONS request to the api endpoint
• When the apiserver runs in the secure mode (with authn), for each request the master will use "m.Handler" to process the request; whereas an "m.InsecureHandler" will be used if running in insecure mode
• The m.InsecureHandler will handle CORS correctly without performing any auth.
• In comparison, the m.Handler will add authn functionality before CORS, as shown here, where the handlers.NewRequestAuthenticator will add auth before the InsecureHandler that handles CORS. In short, in the secure mode, we first authenticate all requests (including OPTIONS) before detecting if it is an OPTIONS request
• Meanwhile (unfortunately), as the OPTIONS request cannot carry any auth headers (by w3c standards), the OPTIONS requests will always fail the authentication.

Is this expected behavior or did I miss anything? If it is expected, then what is the recommended way to allow CORS with authn on? I am thinking of using a proxy in front of the apiserver

[krousey]

cc @lavalamp

[lavalamp]

That seems kinda broken, how can we implement this without leaking
information about whether a resource exists or not?
http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0

BTW, our apiserver is not currently safe against XSS attacks, so we do
intend to make a proxy layer that handles this stuff. See
#10351 (comment).
If you write a proxy layer, we'd love to see it!

On Wed, Oct 28, 2015 at 9:35 AM, krousey notifications@github.com wrote:

cc @lavalamp https://github.com/lavalamp

—
Reply to this email directly or view it on GitHub
#16431 (comment)
.

[pendoragon]

I have come across the same issue. Is it possible to run a nginx proxy in front of apiserver on the master to handle CORS request? it seems that there was a nginx sitting in front of apiserver quite a while ago and all requests will be reverse proxied by nginx. but then it got removed to enable apiserver bearer token auth (nginx does not support bearer token).
#4007

[pendoragon]

also could you explain more on

how can we implement this without leaking information about whether a resource exists or not?

what is the security concern behind having authn handler take precedence over CORS handler rather than the other way around? or we simply don't want to enable cors on security port (because the preflight request will always be rejected)?

[pendoragon]

@lavalamp any update?

[lavalamp]

@pendoragon No update.

As far as what the problem is, OPTIONS not having auth headers means we can't tell if the requester is allowed to see the thing they're asking about.

But anyway, as apiserver is not currently (and possibly not ever) hardened against XSS attacks, if you need CORS, you probably need to run an api proxy that is hardened against XSS attacks.

[xinzhangcmu]

OPTIONS not having auth headers means we can't tell if the requester is allowed to see the thing they're asking about.

@lavalamp could you clarify what information would be leaked if we don't check auth on OPTIONS requests? My understanding is that

• the client sending OPTIONS requests only intends to see if the server allows the client (or a certain origin) to further talk to the server for CRUD operations
• Hence, the only information that is leaking by not checking auth on OPTIONS requests is what origins are allowed for XmlHttpRequests. Is this your concern?

[lavalamp]

I was under the impression that OPTIONS also contains a path, and therefore
the server's response would therefore allow someone to tell if a resource
exists or not? If there's no path in OPTIONS (or there is but it can be
ignored) then I have no objection and we can see if @erictune or @stephenR
agree.

On Fri, Nov 6, 2015 at 2:39 AM, xinzhangcmu notifications@github.com
wrote:

OPTIONS not having auth headers means we can't tell if the requester is
allowed to see the thing they're asking about.

@lavalamp https://github.com/lavalamp could you clarify what
information would be leaked if we don't check auth on OPTIONS requests? My
understanding is that

• the client sending OPTIONS requests only intends to see if the
  server allows the client (or a certain origin) to further talk to the
  server for CRUD operations
• Hence, the only information that is leaking by not checking auth on
  OPTIONS requests is what origins are allowed for XmlHttpRequests. Is this
  your concern?

—
Reply to this email directly or view it on GitHub
#16431 (comment)
.

[pendoragon]

AFAIU, OPTIONS does contain a path but the server will just return 204 regardless of whether the path exits or not. The response to OPTIONS only indicates that server is aware of CORS.

[stephenR]

I agree with @pendoragon, it should be fine to ignore the path in the options request.

[lavalamp]

Thanks for the clarification! In that case it sounds logical to change the
order, and make sure that OPTIONS response does not depend on the path.
I'll happily take a PR that changes this.

On Tue, Nov 10, 2015 at 5:12 AM, stephenR notifications@github.com wrote:

I agree with @pendoragon https://github.com/Pendoragon, it should be
fine to ignore the path in the options request.

—
Reply to this email directly or view it on GitHub
#16431 (comment)
.

[pendoragon]

Thanks for confirmation! I will work on a PR for this!