Change in the JavaScriptServlet doPost() logic in 4.1.1 from 3.1.0

[crkharan]

Currently switching to use 4.1.1 from 3.1.0 version of the library.

The doPost method in the JavaScriptServlet.java class in 3.1.0 first checked if the FETCH-CSRF-TOKEN is present, and if so, fetched the token from the request. But in the 4.1.1 version, first the isTokenPerPageEnabled check is done. And if this property is not enabled, the following error message is thrown: "This endpoint should not be invoked if the Token-Per-Page functionality is disabled!"

Our code sets the property to org.owasp.csrfguard.TokenPerPage = false. I am trying to understand why this change was made and how we can remediate the issue on our side.

@forgedhallpass Could you please help me understand the reason for the change and what would be the best path forward? Thanks!

[aramrami]

Hello,

Adding this feature in 4.1.1 is not an issue in the CSRFGuard. It is an security enhancement to avoid to bypass CSRFGuard using other attacks like XSS for example.

[zhengjiudan]

@aramrami , could you give more details how this new version gets enhanced to avoid XSS attack? If malicious script can steal the tokens from HTTP session, it can also steal tokens from server memory? Thanks!

[forgedhallpass]

@zhengjiudan the difference is that it's hardER to steal page tokens because the endpoint requires a valid master token. That being said, if an attacker has an unrestricted way of running arbitrary JavaScript code on you page, he can ultimately bypass all CSRF protections.

"Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques!"
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

[forgedhallpass]

Hello @crkharan,

In 4.x the code base went through a major refactoring, both on Java and JavaScript side, hence if you're upgrading, you'll have to use the latest version of csrfguard.js.

Currently, the general execution flow in short (non-JSP), is the following:

• script tag in HTML references the JavaScriptServlet. In most cases this needs to be the first resource to be referenced.
• GET request against JavaScriptServlet returns the JS code with an embedded masterToken.
• (Only) if the token-per-page functionality is enabled a (second) POST request against the servlet is made with the masterToken.
  • if the masterToken is correct, and token-precreate is enabled, the response will contain the list of all pageTokens
  • otherwise the page tokens will be generated on first use. At the first access of a protected endpoint, the masterToken is sent along, a unique page token is generated and sent back to the JS logic. From that point on, only that new page token will be accepted for that particular endpoint(or endpoints, because wildcards and regexes can also be used).
  • Note: there might be specific scenarios when automated asynchronous XHR requests are being sent at the page load, before the CSRF Guard logic fully initializes. In that case, the org.owasp.csrfguard.PageTokenSynchronizationTolerance property can be used to specify a grace period in which the masterToken is also accepted instead of already generated pageTokens.

The documentation of the possible configuration properties can be found in the csrfguard.properties file.

There is also a test-jsp module which showcases a default configuration. This can also be used to rapidly test different configurations.

[kallem]

@forgedhallpass I am also upgrading from 3.1 to 4.2. Startup works but I ran into an issue with masterToken not being updated in frontend from initial value and so application runs to CSRF error.

Configuration for tokens

org.owasp.csrfguard.TokenPerPagePrecreate = false
org.owasp.csrfguard.TokenPerPage = true
org.owasp.csrfguard.Rotate = false
org.owasp.csrfguard.Ajax = true

I have added org.owasp.csrfguard.CsrfGuardHttpSessionListener in the web.xml. When session is created there is a new masterToken created but frontend never gets it. The request that creates the session is protected so it is adding token header to response.

The latest csrfguard.js is being used and there masterToken would be saved if received. Requests are processed by CsrfGuardFilter.handleSession and token is added to response as header. I debug code and even masterToken is added as page token and so frontend never sees it as masterToken. Is that intended? I have not set page tokens to be precreated so subsequent protected requests fail because they are done with initial masterToken and that is invalid after login.

I tried to look other places where masterToken would be sent to frontend if I would have missed something in the configuration but found none. Can you give a hint what have I done wrong with the configuration?

[forgedhallpass]

Hello @kallem,

Could you please try to reproduce the issue using the included test-jsp application and create a bug with the required steps if it's also reproducible there?