Token Recipient Confusion: Difference between revisions
No edit summary |
No edit summary |
||
Line 3: | Line 3: | ||
for different SaaS-CPs, each token contains information ''D'' about its recipient. In most cases this is the URL of the SaaS-CP for which the token was generated. | for different SaaS-CPs, each token contains information ''D'' about its recipient. In most cases this is the URL of the SaaS-CP for which the token was generated. | ||
The goal of ''Token Recipient Confusion (TRC)'' is to use an authentication token ''t_A'' generated for a service ''S_A'' on a second service ''S_target''. The attack is considered successful if ''S_target'' becomes “confused” by the recipient of the token and accepts ''t_A'' as valid. | The goal of ''Token Recipient Confusion (TRC)'' is to use an authentication token '''t_A''' generated for a service '''S_A''' on a second service '''S_target'''. The attack is considered successful if '''S_target''' becomes “confused” by the recipient of the token and accepts '''t_A''' as valid. | ||
=Attack subtypes= | =Attack subtypes= |
Revision as of 16:57, 14 January 2016
Attack description
In real-life SSO, there exist multiple SaaS-CPs federating with the same IdP. In order to distinguish the authentication tokens generated for different SaaS-CPs, each token contains information D about its recipient. In most cases this is the URL of the SaaS-CP for which the token was generated.
The goal of Token Recipient Confusion (TRC) is to use an authentication token t_A generated for a service S_A on a second service S_target. The attack is considered successful if S_target becomes “confused” by the recipient of the token and accepts t_A as valid.
Attack subtypes
Prerequisites for attack
The attacker has access to a valid token. An additional requirement is that both services (S_A and S_target) have to be federating with the same IdP. This is a realistic assumption since an IdP usually offers authentication services for multiple SaaS-CPs.
Graphical representation of attack
Attack example
There are two different approaches for a TRC exploit:
Exploit 1: Suppose, that SaaS-CPs S_A and S_target are accepting tokens from the same IdP, and the attacker does not have access to S_target. The attacker does, however, have legitimate account on S_A, thus, he can request a token t_A = (..., D_A, ...) from the IdP. By sending t_A to S_target (instead of S_A), the attack is performed. It is considered successful if t_A is accepted by S_target; the attacker is thus logged in with the same account name as he has for S_A and gets access to S_target’s corresponding resources.
Exploit 2: Alternatively, the attacker can set up his own SaaS-CP (S_bad) offering some service for registered users (e.g., a weather forecast). To authenticate to S_bad, SSO is used and the attacker specifically federates it with the same IdP used by S_target. After that, the attacker lures his victim (a legitimate user of S_target) to register with and authenticate to S_bad. Instead of or in addition to its usual service (weather forecast), S_bad stores all tokens in a database so that the attacker can access them. The attacker can then try to use the tokens to log in on S_target as the victim. The attack is considered successful if an authentication token t_bad issued for the victim for service S_bad is successfully verified on S_target.
Attack mitigation / countermeasures
Practical Attack Examples
References
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).