In this article we will identify security risks in Single Sign-On (SSO) at implementation and application levels. Later we will design a threat profile which can be used as a benchmark in security audits.
Organizations usually deploy multiple simplified applications instead of a single complex application. It considerably reduces the complexity of business process and also helps in implementing strong access control. But with increasing number of applications, authentication and user information management has become a nightmare. Hence Single Sign-On (SSO) technology has emerged as a solution to this problem. As the term suggests, there is a single sign-on for all the applications in the organization.
For implementing SSO, a centralized authentication scheme is required. This authentication scheme authenticates users from its own data store which may be a database, LDAP or any other kind of password repository. The authentication scheme is responsible for signing in the users to all associated applications and logging out from all the applications.
SSO authentication is often clubbed with 2 factor or multifactor authentication, using passwords, hardware or software tokens, smart cards or biometrics or a combination of these.
SSO systems have a major disadvantage in that if the single password is lost; all the applications are at risk.
How SSO Works
- A user accesses the application using his browser. A request is sent to the policy agent.
- Policy agent interprets the request and examines it. If there is no authentication token generated for the user it forwards the request to server.
- Server then invokes the process of authentication and authorization. The server assigns user a unique session identifier and an authentication token.
Security issues over SSO implementation
- Weak Authentication Mechanism – User authentication is the property of SSO as the existence of SSO resolves around it. If a user can bypass authentication process, all the applications are at risk.
- Weak Authorization Mechanism – Organizations have a hierarchy of employees, based upon that the authorities of each employee is defined. Similarly in case of access to the application, roles are assigned to each application user. This process is called authorization. SSO implements access control list to enforce authorization. A weak access control mechanism can enable a user to escalate his privilege and access restricted features of the application.
- Improper session management – Once a user is successfully authenticated to SSO, session is created and a session identifier is assigned to that user. This session identifier should be unique for each concurrent user. All associated applications authenticate users based on the session identifier assigned to that user. An improperly implemented session may lead to complete compromise of users’ account.
- No application whitelisting – A whitelist is an allowed list of application in SSO. Lack of a whitelist may allow a new application to redirect users to a fake page.
- No session expiry – This flaw is observed in SSO implementation where the session is killed in one application but not in others.
Identifying security risks at application level
SSO is associated with different applications hence it should be checked against various application security risks. From security audit perspective below is the list of scenarios which need to be tested to ensure application level security:
- SSO login should thoroughly be tested for injection flaw. The variation depends upon the type of data store used at the backend. If database server is in use, then SQL injection related variations should be tested. Similarly is case of LDAP, LDAP injection variations should be tested.
- Once a user is redirected to some application, the original session should be destroyed and other session with new session identifiers should be generated.
- The user-specific details like authentication token, username should be sent over an encrypted channel to thwart of network sniffing.
- SSO redirects a user to other application based on the URL mentioned in the action value. If this URL is static and user session is not validated with each request a malicious low privilege user who has logged in to the SSO, can copy the URL and directly access it through browser. To prevent this attack user session and role should be validated whenever a new request is received at server. Additionally a random token should be generated by the server and appended with the URL. Again this random token should be validated at server before rendering the page to the user.
- If there is no user activity monitored for a given period of time, the users’ session should be destroyed. Even if there is any inactivity or delay in requests from user while redirecting from SSO page to any application, users session should be expired.
- Try to replay the authentication token to bypass authentication.
- Try to replay authentication token with an expired session identifier to check whether session is actually expired.
- Check whether SSO sends user to an application page through HTTP ‘302’ redirect or ‘201’ forward. If it is ‘201’ forward then an attacker having physical access to users’ system can obtain authentication token by refreshing the application page and capturing the request in an HTTP proxy.
- Check if proper cache control is implemented. Ideally SSO and associated applications should set ‘no-cache’ and ‘no-store’ cache directives.
- Check if account lockout or CAPTCHA is implemented in SSO login page to prevent brute force attack.
There are different SSO solutions available and test cases always vary based upon the type of SSO solution implemented.