direct_post response mode, response with a redirect_uri, and protection against session fixation

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1951

Original Reporter: pedro-felix

In the context of the OpenID4VP draft 18, I’ve have some questions regarding the direct_post response mode, responding with a redirect_uri, and protection against session fixation.

1. The use of a payload containing a redirect_uri when responding to the POST with the Authorization Response, namely the algorithm described in https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-10.5, is only effective when on a same-device scenario, right? If so, the spec should make that information more clearer.
   Even on a same-device scenario, the algorithm on section 10.5 only works if the wallet opens the same user-agent/browser as the one used initially by the user to interact with the verifier, right? If so, that can be an issue when the user has multiple browsers installed.

2. How can the redirect_uri also be usable on cross-device scenarios to protect against session fixation?

   1. Have the UI shown by the resource at the redirect_uri present a code that needs to be presented directly at the verifier (on the initial session between the user and the verifier)?
   2. Are there any more guidelines on how to protect this flow?

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

Hi, direct_post with redirect_uri is meant to be used with both same-device and cross-device. that’s why the text in section 10.5, does not specify which flow it is for.

There is no need for the user to type anything to protect the flow. just like section 11.2 explains, there is a need for a shared secret between the verifier front end and backend:

The Verifier's Response Endpoint MUST include a fresh secret (Response Code) into the redirect URI returned to the Wallet and the Verifier's Response Endpoint MUST require the frontend to pass the respective Response Code when fetching the Authorization Response.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: pedro-felix

Thanks.

On a cross-device scenario, the user-agent opened by the wallet to do the GET on the redirect_uri (returned on the POST of the authorization response), will be on a different browser session than the one that initiated the verification, so how can that information be made available to the initial verifier session?

Using the diagram on section 10.5:

• On step (7) the user-agent opened by the wallet does a GET to the redirect_uri returned on step (6), passing in response_code.
• On step (8) the Verifier fetches response data using (transaction-id, response_code). However, how can the Verifier associate a response_code to a transaction-id, if the session where the verification was initiated (step (1)) is different from the session where step (7) was performed, while still protecting for session fixation?

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

I don’t think it is association between the first session where the verification was initiated (steps 1-4) and the redirect from the wallet in step 7 that prevents this attack.

Let’s say the attacker starts the request with verifier-1, replay it to the victim, victim POSTs the data to the verifier-1’s response_uri, verifier sends the response to the Wallet with the redirect_uri and the response_code. If Wallet successfully redirects the victim to the verifier-1’s front-end, verifier-1’s front-end has correct response_code to fetch the data from the back-end, so the victim will be logged in as the attacker on the victim’s device, because it is a redirect on the same device where the victim’s wallet resides - no value to the attacker. Now, the attacker will try to fetch the data that the victim’s wallet posted to the Verifier-1’s backend before the Verifier-1’s front end does so. However, the attacker cannot do so, because it does not have a response_code because the redirect with the response_code went to the Verifier-1’s front end,.

Hope this helps. (cc: @{5b73d0fb816d1805baacb64f} since I am sure he can explain better :) )

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: judka

Section 10.5 indicates that there is indeed an association between the first session and the verification: “(8) The Verifier sends the response_code and the transaction-id from its session to the Response Endpoint.”
In a cross-device flow, where steps 1-4 happen on a different device than steps 7 and 8, the Verifier won’t have access to the transaction-id to fetch the data from the response endpoint, because it does not have access to the session on the first device where the transaction-id was created. To my understanding, step 8 will always fail in a cross-device flow even in legit cases, or am I missing something?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: fabian-hk

I agree, but I think that's why there's a note in step (8) saying that if no redirect URL is sent, it will just poll the response endpoint.

I don't really understand the use case of starting authentication on one device and sending the response code to a browser on another device. @kristina Yasuda Can you explain this in more detail?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: pedro-felix

This issue was discussed at the 2023-07-14 SIOP Special Topic Call:

• The design at https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-10.5 was initially intended for same-device scenarios.

• This design can be extended to cross-device scenarios by

  • Showing a user code at the device running the Wallet, after the POST with the authorization response at step (5).
  • Having the user insert this code on the Verifier at the device where the verification originated.

• Two options were identified on how the code could be shown at the device running the Wallet

  • Option A - Verifier replies to step (7) with an HTML page containing the code and some informative text on how to use and the precautions that should be taken. No changes to the protocol are needed. Wallet still needs to open a browser. Verifier can determine if the request is from cross-device or same-device, and use that information to shown the code or not after step (7)
  • Option B - Verifier Response Endpoint adds the code and some informative text as fields in the JSON payload of response (6). Wallet shows the code and informative text on its own UI (no need to open a browser). Protocol needs to be changed to accomodate the new fields in step (6). Challenge: how can the Verifier Response Endpoint detect if it is a same-device or cross-device scenario (a same-device scenario doesn't require the user to explicitly insert a code).

• Further security analysis is still required.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: fabian-hk

Thanks for the answer. That makes a lot more sense. But in the cross-device scenario, this only helps if the user pays attention to the URL of the website where they enter the response code, right? So it is similar to the strategy where the user has to check the URL of the verifier in the wallet. I think this is a weak mitigation against the cross-device flow attack because most users will probably not pay attention to it, or am I missing something here?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: pedro-felix

Considering option B:

• The UI shown on the response to step (7) is controlled by the legitimate verifier and it only shows the code and not the place where it should be inserted. It is the user that needs to explicitly go to the UI where they started the flow and insert the code. This UI can also clearly present the context where the code is to be used - E.g. “Did you start a verification process with THE BANK? If so, and if you agree with providing these claims to THE BANK, then use this code to complete the verification process. Make sure the URL where you do that is really www.the-bank.com”.

• So the attacker needs to convince the user to:

  • Scan a provided QR code
  • Complete the flow on wallet
  • Grab the code shown by the legitimate verifier, ignoring the warning information.
  • Insert the code on a page controlled by the attacker

‌

[Sakurann]

@pmhsfelix @fabian-hk has this issue been resolved?

[pmhsfelix]

I don't think so.