CSRF tokens are vulnerable to a BREACH attack

[johnraycp]

Summary

The CSRF tokens generated by Spring are vulnerable to a BREACH attack. More details at http://breachattack.com/

I'll create a pull request with a proposed code change to fix this.

Actual Behavior

Spring always returns the same CSRF token to the browser.

Expected Behavior

The simplest way to mitigate this would be to return a token which is composed of a random per secret request XORed with an internal CSRF token. This effectively means that the browser receives a new CSRF token with each request.

Configuration

This only occurs when you turn on CSRF protection in Spring and also have HTTP compression enabled somewhere in your web server stack.

Version

Currently exists in latest version in Git.

Sample

N/A

[jgrandja]

The proposed solution will be to introduce a default method to CsrfToken, as follows:

public interface CsrfToken {
    …
    default boolean matches(CsrfToken token) {
        return getToken().equals(token.getToken());
    }
}

Then override the default method in DefaultCsrfToken to handle the XOR logic.

Targeted for 5.0 RELEASE which will support Java 8.

[jgrandja]

The proposed solution will be to introduce a default method to CsrfToken, as follows:

public interface CsrfToken {
    …
    default boolean matches(CsrfToken token) {
        return getToken().equals(token.getToken());
    }
}

Then override the default method in DefaultCsrfToken to handle the XOR logic.

Targeted for 5.0 RELEASE which will support Java 8.

[Wadeck]

@jgrandja care about potential timing-attack with your proposal. Using MessageDigest.isEqual could be better at that point.

[Wadeck]

@jgrandja care about potential timing-attack with your proposal. Using MessageDigest.isEqual could be better at that point.