NewTokenLandingPage redirect is a POST?

[LPmaverick]

Shouldn't this be a GET redirect?

[forgedhallpass]

Hello @LPmaverick,

It is recommended not to use GET if the data submitted is potentially sensitive, and I'd say CSRF tokens could be considered as such.

[LPmaverick]

But shouldn't everything about the original request be thrown out? The redirect is to the configured endpoint with 0 parameters from the original request to ensure it is CSRF immune.

[forgedhallpass]

But shouldn't everything about the original request be thrown out?

And you are certain it is not happening that way?

Looking at the logic, it should work correctly. See:

www-project-csrfguard/csrfguard/src/main/java/org/owasp/csrfguard/CsrfGuard.java

Line 333 in f6bacb7

public void writeLandingPage(final HttpServletResponse response, final String logicalSessionKey) throws IOException {

[LPmaverick]

That is happening. So there will be no data sent in the redirect that we would need to worry about, correct?

Also, the redirect endpoint should contain no state-changing functionality and be completely CSRF immune, right? Which would mean that this logic

www-project-csrfguard/csrfguard/src/main/java/org/owasp/csrfguard/CsrfGuard.java

Lines 351 to 357 in f6bacb7

	if (new CsrfValidator().isProtectedPage(landingPage).isProtected()) {
	stringBuilder.append("var hiddenField = document.createElement(\"input\");")
	.append("hiddenField.setAttribute(\"type\", \"hidden\");")
	.append(String.format("hiddenField.setAttribute(\"name\", \"%s\");", getTokenName()))
	.append(String.format("hiddenField.setAttribute(\"value\", \"%s\");", getTokenService().getTokenValue(logicalSessionKey, landingPage)))
	.append("form.appendChild(hiddenField);");
	}

isn't needed.

[LPmaverick]

If the endpoint is protected in the application, then I see that as an issue within the application.

[forgedhallpass]

So there will be no data sent in the redirect that we would need to worry about, correct?

There is a test application in the project exactly for the purpose of testing different configurations and scenarios. Please use it.

Which would mean that this logic ... isn't needed

The logic above is needed, because you might decide to include CSRF protection for the new token landing page. It's totally up to you.

If the endpoint is protected in the application, then I see that as an issue within the application.

I don't see what issue are you talking about. You control the endpoint, and you control whether you want it expect CSRF tokens or not. If you happen to find a problem, please create an issue with a detailed description, steps on how to reproduce it and the actual vs expected behavior.