Understanding the Session Fixation Attack on UMA Claims-Gathering and the Provided Mitigation

...

On January 27, 2016, an issue was reported that identified a vulnerability in the UMA protocol. The UMA Work Group immediately set about analyzing the attack, possible mitigations under consideration, and similar cases; choosing an optimal mitigation; and developing specification text (add link) defining that mitigation. This companion non-normative document provides additional background information.

...

See the complete attack sequence in the extension specification (add link) UMA Claims-Gathering Extension for Enhanced Security.

The attack relies on the attacker initiating the resource access attempt, phishing the legitimate requesting party into completing one or more claims-gathering flows at the authorization server, and then taking over the session once again to accept an RPT that contains the desired authorization data that allows inappropriate access to the resource.

...

• The state parameter provides no support to distinguish the attacker's transaction context and the victim's context. The victim's client simply fails when attempting to continue seeking access because the session was initiated by the attacker. The transaction context of record is the attacker's.
• The ticket parameter provides no support to distinguish the two contexts because UMA V1.0 and V1.0.1 (and possible future minor versions) require its value to be the same across the entire process of claims-gathering when a requesting party is seeking access to a particular resource. It could be said that the root problem of the session fixation is in the "fixed" nature of permission tickets in the cycle of 1) requesting party claims endpoint usage with a ticket parameter and 2) the response from the AS with the same ticket parameter repeated.

Discussion of the Provided Mitigation and Others Considered

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

The mitigation involves a new requesting party claims endpoint at the authorization server that behaves differently from the original one, in that it returns a ticket parameter value that is unguessable rather than the same value it was given originally; the authorization server also invalidates the original ticket. This has the effect of adding entropy to the round-trip permission ticket cycle during the claims-gathering flow, foiling an attacker's ability to know all the information necessary to simulate a true requesting party's request for an RPT and authorization data in step 7 in the attack sequence.

...