Bug 2359554 (CVE-2025-24358, GHSA-rq77-p4h8-4crw)

Summary: CVE-2025-24358 gorilla/csrf: gorilla/csrf CSRF vulnerability due to broken Referer validation
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in gorilla/csrf. Affected versions of gorrila/csrf are vulnerable to CSRF via form submission from origins that share a top level domain with the target origin. This vulnerability allows an attacker who has gained XSS on a subdomain or top level domain to perform authenticated form submissions against gorilla/csrf protected targets that share the same top level domain.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2359633, 2359634, 2359635, 2359636    
Bug Blocks:    

Description OSIDB Bzimport 2025-04-14 17:01:30 UTC 
### Summary

gorilla/csrf is vulnerable to CSRF via form submission from origins that share a top level domain with the target origin.

### Details

gorilla/csrf does not validate the Origin header against an allowlist. Its executes its validation of the Referer header for cross-origin requests only when it believes the request is being served over TLS. It determines this by inspecting the `r.URL.Scheme` value. However, this value is never populated for "server" requests [per the Go spec](https://pkg.go.dev/net/http#Request), and so this check does not run in practice. 
```
	// 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)
```

### PoC

- create trusted origin `target.example.test` protected with gorilla/csrf and served over TLS hosting form on `/submit`
- create attacker origin `attack.example.test` served over TLS
- attacker exfiltrates token & cookie combination from `target.example.test` 
- attacker sets exfiltrated cookie with `domain=.example.test and path=/submit`
  - as the cookie has a more specific path than `/` (the default for CSRF cookies) it will be sent first by the browser on submit to our target origin
- submit form from `attack.example.test` with exfiltrated CSRF form token
- observe valid form submission as `attack.example.test` Origin / Referer headers are not validated. 

### Impact

This vulnerability allows an attacker who has gained XSS on a subdomain or top level domain to perform authenticated form submissions against gorilla/csrf protected targets that share the same top level domain.

This bug has existed in gorilla/csrf since its initial release in 2015.