Category:Attack Categorisation By Attacked Single Sign-On Component and Category:Attack Categorisation By Attacker Model: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
No edit summary
 
No edit summary
 
Line 1: Line 1:
Using authentication via ''Single Sign-On (SSO)'' has many advantages over simple Username/Password mechanisms. Whereas for the former, the user has to remember multiple different Username/Password combinations, this overhead can be significantly reduced with ''SSO''. Also, the security of Username/Password relies solely on the strength of the password provided by the user, but ''SSO'' allows for the adoption of several technical measures to further enhance the security of the login procedure. <br>
This page lists three different attacker models. Each attacker type has different capabilities.
In general, authentication using ''SSO'' is done utilizing a trusted third party called ''Identity Provider (IdP)''. When a user uses his user agent (UA), e.g., a web browser, to request a login to the service provider ''(SaaS-CP)'', instead of asking for Username/Password, the service issues a Token Request and redirects the client to the ''IdP''. After proper authentication, the ''IdP'' issues a signed authentication ''token (Token)'' and redirects the client back to the ''SaaS-CP'', where the token will be validated and the user logged in. <br>
All of attacker models do not require the attacker to control the network communication.
As can be seen in Figure 1, the Service Provider contains the different security-related components:
*Message Generation [http://www.sso-attacks.org/Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks] <br>
*''Client'' is a user communicating with an ''SaaS-CP'' via his UA, for example, a web browser. The communication takes place via the HTTP Protocol.)
The attacker is able to generate valid XML messages of the service provider specified format. These messages can be of any publicly available XML format
*''Web Frontend''(for example, a web server listening on a specific port and forwarding the traffic to the according handlers)
(plain XML, SAML, XSLT, DTD etc.) and can contain any data which is publicly available or chosen arbitrarily by the attacker.
*''Username/Password'' module manages the corresponding authentication and the password-recovery mechanism
*Access to Valid Token [http://www.sso-attacks.org/Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token] <br>
*''Session Management (SM)'' module resolves the received Session Cookies by the ''Web Frontend'' to a user identity and forwards this information to ''Authorization & Access Management (AAM)''
The attacker having access to a valid token '''t = (I, N, D)''' (I = Identity, N = Freshness, D = Destination) of the victim, including the corresponding signature '''s = SIG_IdP(t)'''. A special case of this attack model occurs, when the attacker himself is a valid user of the system. He can then use his credentials on his '''IdP''' to let it issue tokens for his own account on demand (but not for the victim account).
*''SSO module'' carries out the verification of the received authentication
*Web attacker [http://www.sso-attacks.org/Category:Attack_Categorisation_By_Attacker_Model:_Web_Attacker] <br>
tokens and contains three internal modules:
The attacker is able to influence the victim to click on an attacker provided link. This includes both, a technical method to provide an attacker generated link to the user (e.g., by e-mail or through user forums), and the technical and/or social means to convince the user to actually activate (i.e. click on) the link.
    '''The Parser''' (converts an input string into data objects, which can then be further processed by following components)
    '''Verificator''' (validation of all security-relevant parameters within the authentication token)
    '''Processor''' (after the verification, the information regarding the authenticated user will be extracted from the token and forwarded to the business logic)
'''These internal modules are considered as potentially violated targets'''.
*''Authorization & Access Management (AAM)'' controls the access to the restricted resources
*''User Database'' stores information about users and their credentials
*''Resources'' include the entirety of data accessible to registered users
[[File:Authentication_Process_Saas-SP.jpg|centre]]

Revision as of 16:30, 2 February 2016

This page lists three different attacker models. Each attacker type has different capabilities. All of attacker models do not require the attacker to control the network communication.

  • Message Generation [1]

The attacker is able to generate valid XML messages of the service provider specified format. These messages can be of any publicly available XML format (plain XML, SAML, XSLT, DTD etc.) and can contain any data which is publicly available or chosen arbitrarily by the attacker.

  • Access to Valid Token [2]

The attacker having access to a valid token t = (I, N, D) (I = Identity, N = Freshness, D = Destination) of the victim, including the corresponding signature s = SIG_IdP(t). A special case of this attack model occurs, when the attacker himself is a valid user of the system. He can then use his credentials on his IdP to let it issue tokens for his own account on demand (but not for the victim account).

  • Web attacker [3]

The attacker is able to influence the victim to click on an attacker provided link. This includes both, a technical method to provide an attacker generated link to the user (e.g., by e-mail or through user forums), and the technical and/or social means to convince the user to actually activate (i.e. click on) the link.