Page Comparison

...

1. The attacker attempts access to an UMA-protected resource at an RS that she should not be able to access.
2. The RS registers a requested permission; the AS returns a permission ticket; the RS returns a permission ticket (along with other data) to the client.
3. The client asks for authorization data and RPT at the AS; the AS returns a need_info response with an error_details block containing a redirect_user hint (or, if there is no such hint, the client otherwise infers the requirement to redirect the victim's browser to the requesting party claims endpoint).
4. The client attempts to redirect the victim's browser to the requesting party claims endpoint, but the attacker prevents this redirection, and instead copies the redirect URL (optionally stripping off the state parameter), including a permission ticket query parameter, and passes it to the victim.
5. After being phished with the URL, the victim assists the AS in completing the claims-gathering process, for example, proving his identity and providing any other required claims in order to allow access to the desired resource. The victim notices nothing wrong; it looks like he's supplying claims to help launch a client he knows and trusts. In the case of long-lived cookies for, say, social networks, the victim’s claims could be provided to the AS automatically through single sign-on.
6. The AS redirects the victim back to the client. No relevant session is found in the client because either no state value or an incorrect state value is present on the request [(correct?]). Therefore, the POST-redirect request fails. Alternatively, if an attacker controls the victim's network access, she can prevent all communication between victim and client, so the client doesn't see a spurious/failed request at all.
7. After the right amount of time has elapsed, the attacker simulates the any required post-claims-gathering actions in her client, ultimately receiving an RPT with sufficient authorization data, because every parameter of the post-claims-gathering endpoint (state, authorization_state, ticket) is known to the attacker.
8. The attacker gains access to the protected resource.

...

The attack is possible even if the AS does not return returns a need_info with any particular hints response with no error_details block or no specific redirect_user hint to the client. Out-of-band agreements are possible between these two entities that can indicate that redirection is the next expected action.

It is possible for various types of claims-gathering flows to be repeated, or even for claims-gathering and other methods of trust elevation to be conducted in some "chain" prescribed by the ASthe redirection cycle to be repeated multiple times before the victim is finally returned to the client. In other words, in Step 7 described above, the "post-claims-gathering actions" may include additional claims-gathering and/or other trust elevation methods; in the former case, the same attack could be applied repeatedly.No evidence was found, in our analysis, of other methods of trust elevation present in the UMA Core V1.0 or V1.0.1 specifications (pushed claims or step-up authentication) being susceptible to this attack.

The Provided Mitigation

The UMA Work Group has provided a mitigation of this attack in the form of an extension specification (add link).

...