CVE-2023-29020

@fastify/passport is a port of passport authentication library for the Fastify ecosystem. The CSRF (Cross-Site Request Forger) protection enforced by the @fastify/csrf-protection library, when combined with @fastify/passport in affected versions, can be bypassed by network and same-site attackers. fastify/csrf-protection implements the synchronizer token pattern (using plugins @fastify/session and @fastify/secure-session) by storing a random value used for CSRF token generation in the _csrf attribute of a users session. The @fastify/passport library does not clear the session object upon authentication, preserving the _csrf attribute between pre-login and authenticated sessions. Consequently, CSRF tokens generated before authentication are still valid. Network and same-site attackers can thus obtain a CSRF token for their pre-session, fixate that pre-session in the victims browser via cookie tossing, and then perform a CSRF attack after the victim authenticates. As a solution, newer versions of @fastify/passport include the configuration options: clearSessionOnLogin (default: true) and clearSessionIgnoreFields (default: [passport, session]) to clear all the session attributes by default, preserving those explicitly defined in clearSessionIgnoreFields.

Weakness

The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.

Affected Software

Potential Mitigations

• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
• For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330]
• Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
• Use the “double-submitted cookie” method as described by Felten and Zeller:
• When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user’s machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.
• Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult.
• This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/111.html
• https://cwe.mitre.org/data/definitions/462.html
• https://cwe.mitre.org/data/definitions/467.html
• https://cwe.mitre.org/data/definitions/62.html

References

• https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern
• https://github.com/fastify/fastify-passport/commit/07c90feab9cba0dd4779e47cfb0717a7e2f01d3d
• https://github.com/fastify/fastify-passport/security/advisories/GHSA-2ccf-ffrj-m4qw
• https://owasp.org/www-community/attacks/csrf