search

aspnet / Antiforgery

[Archived] AntiForgery token feature for ASP.NET Core. Project moved to https://github.com/aspnet/AspNetCore
Apache License 2.0
78 stars 40 forks source link

Protocol validation #159

Closed zygimantas closed 7 years ago

zygimantas commented 7 years ago

Actual result

If a reverse proxy is used, it's a common practice to terminate SSL on IIS/Nginx. Sometimes there is no practical need make secure connection between reverse proxy and Kestrel (public/private key distribution, storing certificate password, etc.).

There is a cookie flag "Secure" (wikipedia: A secure cookie can only be transmitted over an encrypted connection (i.e. HTTPS). They cannot be transmitted over unencrypted connections (i.e. HTTP). This makes the cookie less likely to be exposed to cookie theft via eavesdropping. A cookie is made secure by adding the Secure flag to the cookie.).

If the "Secure" flag is set to true, XSRF validation fails because browser sends a cookie (browser sends request over HTTPS), but aspnet core fails because the cookie header is received over HTTP.

System.InvalidOperationException: 'The antiforgery system has the configuration value AntiforgeryOptions.Cookie.SecurePolicy = Always, but the current request is not an SSL request.'

Expected result

There should be an option to disable protocol validation - there should be a way to use secure flag even if the SSL is terminated by reverse proxy, because the browser does not see any deeper.

Tratcher commented 7 years ago

We address this across the stack by having the reverse proxy forward the original scheme in an x-forwarded-proto header. The UseForwardedHeaders middleware reads these and modifies the request accordingly. See the samples in the BasicMiddleware repo. UseIISIntegration wires this up by default for IIS scenarios.