State nonce cookie should properly be signed

[Hanspagh]

Reading auth0.com/docs/secure/attack-protection/state-parameters it is suggested that the state once for CFSF protected in stored in a signed cookie, to my understanding this is not the case at the moment.

[yordis]

@Hanspagh what part is the one we are missing, here is the line

ueberauth/lib/ueberauth/strategy.ex

Line 391 in 7ebc0ae

|> Conn.put_resp_cookie(@state_param_cookie_name, state, same_site: "Lax")

Is there an extra configuration we need to pass to Conn.put_resp_cookie?

[Ajwah]

@yordis

The details are here: https://hexdocs.pm/plug/Plug.Conn.html#put_resp_cookie/4-signing-and-encrypting-cookies

I have been looking into the security exploitations of this vulnerability. If the cookie is not signed, then I believe you are setting the users of this library open to a callback url attack, and allow the attacker to impersonate any user.

The assumption of the security of the state-param is based on your believe that:

1. All users are using browsers
2. First the user accesses the endpoint: /auth/google to trigger the whole oauth flow(it is at this endpoint you are setting the nonce value in the cookie)
3. Lastly, Google redirects the user to /auth/google/callback with all relevant oauth2 details, such as access token, refresh token and id token. Before decoding any of these tokens, you compare the value of the state-param to correspond to the value of the cookie client side.

When all is well, you decode the JWT tokens and extract the various values of the oauth providers; which allows you to get email address of a user

If this cookie value is not properly signed; then your security falls apart by realizing that a malicious attacker will only adhere to point 3. The malicious attacker is NOT using a browser but rather a command line tool such as curl; allowing him to spoof any value occurring in the params of a request to: /auth/google/callback:

1. Spoof the cookie header with a nonce value of your choosing
2. Spoof the state-query param with the exact same value
3. Craft your own id token etc. where you ensure the email corresponds to that of any user you would like to impersonate.

According to Ueberauth, this request is now authenticated and the attacker will have access to a cookie or a JWT that the website in question will take at face value and thereby gives full unrestricted access to the malicious attacker.

The only saving grace here would be if ueberauth_google(or perhaps the underlying library oauth2) were to factually validate the id-token as it comes from Google against the public key: https://www.googleapis.com/oauth2/v3/certs. Without the private key, it will not be possible for an attacker to make the above exploitation.

Is this the case? I have not dug any further. However, security should be layered; so ensuring that the cookie is properly signed would help guarantee that the issuer of that cookie was the signer of that cookie.