CORS preflight OPTIONS requests should bypass authentication

[nitper]

Describe the bug
Pomerium is requiring authentication for http OPTIONS requests, but the spec says OPTIONS requests should not include user credentials. These requests should be passed downstream without authentication.

To Reproduce Steps to reproduce the behavior:

Browser on https://bob.corp.domain.com/ makes a CORS request to https://alice.corp.domain.com/ like this:

curl 'https://alice.corp.domain.com/api/route' -X OPTIONS -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Access-Control-Request-Method: POST' -H 'Access-Control-Request-Headers: content-type' -H 'Origin: https://bob.corp.domain.com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: https://bob.corp.domain.com/some/route' -H 'TE: Trailers'

Pomerium will try to redirect to the authentication provider.

Expected behavior

Pomerium should not require auth for HTTP OPTIONS requests.

Environment:

• Pomerium version (retrieve with pomerium --version): v0.0.3+41c42f5
• Server Operating System/Architecture/Cloud: ubuntu 18.04, running on EC2 behind an elastic ip

Configuration file(s):

Logs(s):

ERR authenticate: failed to load session error="http: named cookie not present" 
WRN authenticate: authenticate error error="http: named cookie not present" 

[nitper]

I did some searching around, and there are a bunch of other proxy projects that have implemented this. Here's one example https://github.com/istio/proxy/issues/651

[desimone]

Hi @nitper thank you bug report.

I didn't know that about OPTIONS. We should conform to the spec, but I would like to better understand the use-case and investigate a bit regarding any potential security implications of having a bypass.

Could you point me in the direction right direction to read more about OPTIONS?

Ref for later self:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS
• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

[nitper]

Your second link as well as the spec I posted originally are the best resources I have seen. There are various blog posts out there but they all seem to reference these two links.

There's also this page https://enable-cors.org/server.html which links to this handy server flowchart. Since Pomerium is a proxy, I believe it should verify that an OPTIONS request has all the necessary headers to qualify it as preflight, and then forward that to the server without authentication.

I'll need to double-check this, but it seems the preflight OPTIONS request must include these headers:

• Access-Control-Request-Method
• Access-Control-Request-Headers

---

For what it's worth, my downstream server is using Echo as the server with the CORS middleware.

My frontend is using axios setting withCredentials: true

  // `withCredentials` indicates whether or not cross-site Access-Control requests
  // should be made using credentials
  withCredentials: false, // default

Pomerium is working just fine with this setup for CORS simple requests

[nitper]

@desimone I'd be happy to submit a PR.

I was thinking about adding a field cors_allow_preflight (not married to the name) to Policy with a default of false. This way the user can manually and intentionally enable the unauthenticated passthrough of OPTIONS requests for each route as needed.

What do you think?

[desimone]

@nitper Thank you, a PR would be greatly appreciated!

I think the field name of cors_allow_preflight makes sense, and agree that defaulting to "off" is a safe choice.

More reading for future travelers:

• https://security.stackexchange.com/questions/21413/how-to-exploit-http-methods
• https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)#Arbitrary_HTTP_Methods
• https://blog.fuzzing-project.org/60-Optionsbleed-HTTP-OPTIONS-method-can-leak-Apaches-server-memory.html