v4.3.0 | In memory Token saving with no clean up leading to High Heap utilization and thus crashing JVM

[Shishir53]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Run CSRF Test application.
2. visit one unprotected page. It generates one token.
3. Make a call to invalidate session on home page.
4. It leads to OnSessionDestroyed() call via listener and then via filter it goes to handlesession() via csrfguardfilter. Here the session key which was used to remove the token is used again by handlesession and one new token is generated with this session key. This token is not being used further, but if this scenario is tested under heavy load, such unused tokens are generated and thus object size of concurrentHashmap grows up and sunbesequently crashing out JVm with error 'out of Memory'.

Expected behavior
No unused extra token to be generated.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):
This is happening irrespective of being hosted in tomcat or websphere.

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[Shishir53]

see discussion for detailed information like root cause and others: #351

[forgedhallpass]

Hello @Shishir53,

Have you encountered this issue in a production environment, or only in the test application?

In the test application, when the session is invalidated, all tokens associated with the session key are correctly removed from the TokenStore, but indeed it appears that the CSRFGuard filter is invoked again before the session is fully invalidated. This leads to a new token being generated immediately after the old one is removed.

A typical implementation would use a dedicated logout endpoint or servlet that handles session invalidation before the filter is executed. That approach would likely avoid this behavior.

That being said it was a good catch. Thanks for taking the time to report it.

Would you be interested in submitting a pull request with a proposed fix or improvement?

[Shishir53]

Hi @forgedhallpass ,

Thanks for responding, I got this issue from production environment once the product was updated to use v4.3.0 of CSRFGuard library from v3.1.0. In Production the issue was that token size was growing too fast, in memory space was used, when we checked single page visit, that too unprotected and token per page was false, and token size respectively then found the issue. After that I checked the test application and found similar behavior there.

Since I preferred to do the fix at my application side rather than changing csrfguard behaviour in the library, for quick fix we created a wrapper around the csrfguard filter and inside it's handlesession before generation of token, placed a check of unprotected page/method using existing method. Here I prevented tokens being generated on unprotected pages and since application is mostly API based (Web UI has very limited user) and csrfguard lib implementation is done for UI only, this seemed most appropriate fix.

This has somewhat resolved our issue of memory leak but we would still like to see 'what should be more generic change to handle a scenario like this at the library level'. I'm open to a discussion over call, if needed.

Thanks,
Shishir Mishra