spring-projects / spring-projects/spring-security

6.5.0-M3 - passkeys csrf token handling not compatible with CookieCsrfTokenRepository

Open
#16,846 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

status: waiting-for-triage type: bug
Dominant language
Java
Stars
9.6k
Forks
6.3k
Avg merge
2d 11h
Merged PRs (30d)
52

Description

Describe the bug
we are using CookieCsrfTokenRepository with a SpaCsrfTokenRequestHandler as outlined in the docs: https://docs.spring.io/spring-security/reference/6.5/servlet/exploits/csrf.html#csrf-integration-javascript-spa

that means

  • csrf tokens passed in the X-XSRF-TOKEN header are expected to be plain because they are retrieved from the corresponding cookie making them BREACH-safe
  • csrf tokens passed in the _csrf request parameter are expected to be "xor-ed"/masked for BREACH-protection

the default passkey registration/authentication javascript uses the masked csrf token from the CsrfToken.class.getName() request attribute and sends it in the X-XSRF-TOKEN header.
that results in a 403 Forbidden.

To Reproduce

  • see the sample app, especially SecurityConfig
  • run the sample app
  • go to http://localhost:8080/login and log in as user / ***
  • go to http://localhost:8080/webauthn/register and try to register a passkey
  • see 403 in browser console

Expected behavior
the default passkey registration/authentication javascript should check for the existence of a readable XSRF-TOKEN cookie (set by CookieCsrfTokenRepository) and if present, use that instead of the token retrieved from the CsrfToken.class.getName() request attribute.

Sample

sample app will be referenced asap.

Misc

current ugly workaround in SpaCsrfTokenRequestHandler: we check if the the token passed in the X-XSRF-TOKEN header represents a valid UUID,

  • if yes - use CsrfTokenRequestAttributeHandler
  • if no - use XorCsrfTokenRequestAttributeHandler
    /**
     * FIXME: remove UUID-check workaround when spring-security passkey default pages support {@link org.springframework.security.web.csrf.CookieCsrfTokenRepository}
     */
    @Override
    public String resolveCsrfTokenValue(HttpServletRequest request, CsrfToken csrfToken) {
        String headerValue = request.getHeader(csrfToken.getHeaderName());
        if (StringUtils.isNotBlank(headerValue)) {
            try {
                UUID.fromString(headerValue);
                return csrfTokenRequestAttributeHandler.resolveCsrfTokenValue(request, csrfToken);
            } catch (IllegalArgumentException e) {
                // noop
            }
        }
        return xorCsrfTokenRequestAttributeHandler.resolveCsrfTokenValue(request, csrfToken);
    }

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the failure in the sample app, starting with its SecurityConfig and the default passkey registration/authentication JavaScript. Trace how the X-XSRF-TOKEN header is populated from the CsrfToken request attribute, then verify behavior with a readable XSRF-TOKEN cookie from CookieCsrfTokenRepository. Done means registration and authentication no longer return 403 with that repository and existing CSRF behavior remains covered.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, javascript, spring
Domain
authentication, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.