WordPress/application-passwords

Should the state parameter be mandated?

Closed this issue · 1 comments

The OAuth 2 spec defines a state parameter that can be used to help prevent CSRF attacks as described by https://tools.ietf.org/html/rfc6749#section-10.12

A CSRF attack against the client's redirection URI allows an attacker
to inject its own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g., save
the victim's bank account information to a protected resource
controlled by the attacker).

The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent). The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.

The state parameter would be included in the request to authorize-application.php, and passed back to the client when the user is redirected.

Due to how OAuth validates the redirect_uri, the state must be handled as a separate parameter. Otherwise, the redirect_uri would be rejected for including a value that wasn't included in the registered uri. However, since we have no uri registration, realistically apps could just include it on their own in the success_url.

Requiring apps to pass a state parameter could encourage best practices, but we wouldn’t be able to enforce that they validate its contents.

We decided not to mandate this.