How is JavascriptServlet browser caching supposed to work?

[bpapez]

We are in the process of switching from csrfguard 3.1.0 to 4.1.1 , but we see a probably wrong behavior of browser caching the csrfguard Javascript, when TokenPerPage is false. The Javascript contains the master token value, however whenever a user logs out and logs in again, a new HTTP session is created and thus also a new master token value. But as the user still is in the same browser window and the Javascript got cached due to this setting:
org.owasp.csrfguard.JavascriptServlet.cacheControl = private, max-age=28800
still the Javascript with the previous master token is used, obviously leading to CSRF errors.

In 3.1.0 this cacheContol setting was quite the same (it did not have the hyphen), however as we had org.owasp.csrfguard.Ajax=true the javascript also did a POST request to the very same URL in this part:

    if (isValidDomain(document.domain, "%DOMAIN_ORIGIN%")) {
        var token_name = '%TOKEN_NAME%';
        var token_value = '%TOKEN_VALUE%';
        /** optionally include Ajax support **/
        if (%INJECT_XHR% == true) {
            if (navigator.appName == "Microsoft Internet Explorer") {
                hijackExplorer();
            } else {
                hijackStandard();
            }

            var xhr = window.XMLHttpRequest ? new window.XMLHttpRequest : new window.ActiveXObject("Microsoft.XMLHTTP");
            var csrfToken = {};
            xhr.open("POST", "%SERVLET_PATH%", false);
            xhr.setRequestHeader("FETCH-CSRF-TOKEN", "1");
            xhr.send(null);

and due to that POST the browser cache got invalidated, so the next GET request again returned the Javascript from the server. This way we always had the latest master token for the session - also for instance if a Rotate happened after an error.

With csrfguard 4.x this POST no longer happens - there is only a POST if TokenPerPage is true. So in my eyes the current Javascript logic and browser cache can no longer work, so one should rather set:
org.owasp.csrfguard.JavascriptServlet.cacheControl = no-cache, no-store

Is there a better solution or am I perhaps missing something here?

[forgedhallpass]

Hello @bpapez,

Starting from 4.x the master token is indeed sent with the initial JavaScript. The reason behind this was to reduce the number of requests needed for the initialization, and also this enabled me to require a token to retrieve the page tokens.

The solution is indeed to disable the cache, or maybe have some custom logic that would force cache revalidation at log-out or re-login. A simple CTRL+F5/R on the user side should also work.

[sloescape]

I am encountering the same issue when migrating to csrfguard 4. However I am struggling with the justification for the change to put the master token into the javascript. Previously the javascriptservlet.js could be cached in the browser and there was a small ajax request to retrieve the token. This has now been replaced by having to retrieve the complete javascript on every request, and the server has to regenerate the javascriptservlet.js for every request (16 kb) with all the work on the server of regenerating the replacement values and then replacing them into the template javascript file. It does not seem like a good trade-off.