gorilla/csrf CSRF vulnerability demo

What

This page demonstrates a CSRF vulnerability in the gorilla/csrf Go library. This vulnerability exists in all published versions of gorilla/csrf since its initial release.

NB: This vulnerability requires the ability for the attacker to set cookies that will be sent to the target origin. The demonstration attack achieves this by hosting the CSRF entrypoint on an origin that shares a common top level domain with the target.

How

gorilla/csrf does not validate the Origin header of incoming requests against an allowlist and instead performs CSRF validation by inspecting the Referer header. These Referer header checks only run when it believes the request is being served over TLS but due to a mishandling of the net/http.Request API these checks never run in production.

Specifically gorilla/csrf inspects the value of r.URL.Scheme to determine whether the request is being served over TLS

if r.URL.Scheme == "https" {
    // Fetch the Referer value. Call the error handler if it's empty or
    // otherwise fails to parse.
    referer, err := url.Parse(r.Referer())
    if err != nil || referer.String() == "" {
        r = envError(r, ErrNoReferer)
        cs.opts.ErrorHandler.ServeHTTP(w, r)
        return
    }
    ...

However, per the Go spec, this field is never populated for "server" requests.

// URL specifies either the URI being requested (for server
// requests) or the URL to access (for client requests).
//
// For server requests, the URL is parsed from the URI
// supplied on the Request-Line as stored in RequestURI.  For
// most requests, fields other than Path and RawQuery will be
// empty. (See [RFC 7230, Section 5.3](https://rfc-editor.org/rfc/rfc7230.html#section-5.3))
//
// For client requests, the URL's Host specifies the server to
// connect to, while the Request's Host field optionally
// specifies the Host header value to send in the HTTP
// request.
URL *[url](https://pkg.go.dev/net/url).[URL](https://pkg.go.dev/net/url#URL)

But what about the unit tests?

Unfortunately the net/httptest.NewRequest helper function that the gorilla/csrf test suite relies on contains a subtle bug whereby it will populate the r.URL.Scheme field on requests that it creates when passed a full URL string. This results in http.Request objects unlike any that will exist in production allowing unit tests to pass that would otherwise fail.

Here is a Go playground that demonstrates the httptest.NewRequest behavior in question.