Token Recipient Confusion: Difference between revisions
(Created page with "=Attack description= =Attack subtypes= =Prerequisites for attack= =Graphical representation of attack= =Attack example= =Attack mitigation / countermeasures= =Prac...") |
No edit summary |
||
Line 1: | Line 1: | ||
=Attack description= | =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= | =Attack subtypes= | ||
Line 6: | Line 9: | ||
=Prerequisites for attack= | =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= | =Graphical representation of attack= | ||
Line 12: | Line 15: | ||
=Attack example= | =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'''. | |||
Revision as of 15: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).