CSRF token failures

[LindseySaari]

Description

A VFS team reported CSRF token failures errors for file uploads. We identified the issue to be related to how the frontend polls Vets API endpoints along with having multiple browser tabs open. Essentially, if a user starts with one browser tab, leaves it idle for > 30 min (the session timeout) and then authenticates in another browser tab, the first browser tab (for some endpoints/forms) will continue to poll the API. Since the second browser tab has reset the session, browser 1 is unauthorized and the CSRF token has also changed. Browser one no longer has a valid session, but continues to poll.

Solution: The frontend needs to identify when a session is gone (when they are getting 401 or 403 http responses) and they need to adjust the current behavior to log out a user instead of continuing to hit the endpoint (since the browser tab is holding onto a csrf token from an old session). The CSRF issue has been going on for quite some time. The DisabilityCompensation form is one that needs to alter their behavior amongst other forms the implement polling on the frontend. We should identify some standards around this behavior.

Debugging

The issue was passed to the backend team to debug the errors, as Vets API implements CSRF protection. On each request, Vets API essentially stores a CSRF token on the session (redis) AND returns the same (masked) token via a response header. The frontend then stores the token in localStorage and passes the token back to the API in subsequent requests via a request header X-CSRF-Token.

Theory of what is happening:

• Browser 1 has in progress form open, been idle for >30 min
• Browser 2 logs in and resets the session
• Browser 1 continues to make requests but now they are unauthorized (and CSRF hits first, so we get the CSRF error)

In this example, you can see where the CSRF token fails over and over again in a loop. The "looping" boils down to the polling behavior.

We were able to identify the multiple browser tab theory in a lower environment.

Details

See this long thread for additional details

Original Ticket from Platform Support

Another way to view the CSRF

[va-albers]

Hi @LindseySaari - have you heard any update on status for this item from the Platform team? It seems like this is a problem across va.gov apps/teams?

[CBonade]

@va-albers the determination was made as a result of the information above that this was an issue that likely needed to be addressed on a team by team basis. There was not any platform-centric code that could be located that was responsible for handling these tokens in our inquiries. We've had a few teams reach out and tell us this hasn't impacted them so we have passed the guidance above along for support to have as a reference, but Platform has no current plans to address this. Is there something additional that you are concerned about past what's written in the assessment Lindsey wrote?

[CBonade]

There's been a few followups on this:

This support thread: https://dsva.slack.com/archives/CBU0KDSB1/p1689721450533939

These two frontend COP Slack Threads: https://dsva.slack.com/archives/C04868KS69L/p1689779593866569 https://dsva.slack.com/archives/C04868KS69L/p1689964953525849

At this time, everything we see points to the save-in-progress feature being the source of this issue. If it turns out otherwise, we are happy to reevaluate. However, our current evaluations have failed to show platform code responsible for this.

Per @little-oddball, removing the FE COP labels and tagging the design system and forms team, with hopes of getting this investigated by the forms team for further evaluation.

[caw310]

Removing DST label since this isn't a DST issue.