Technical Note: Precautions Against Cookie Hijacking in an Access Manager Deployment

Defining Key Cookie Hijacking Security Issues

The tasks presented in this document address specific security issues related to session-cookie hijacking. This section defines those security issues.

The term “cookie hijacking” simply refers to a situation where an impostor (a hacker, perhaps using an untrusted application) gains unauthorized access to cookies. Therefore, cookie hijacking, by itself, does not refer to unauthorized access to protected web resources. When the cookies being hijacked are session cookies, then cookie hijacking potentially increases the threat of unauthorized access to protected web resources, depending upon how the system is configured.

This section provides background information about specific security issues related to session-cookie hijacking, illustrating how this type of cookie hijacking is possible and how it can potentially lead to unauthorized access of protected web resources. This section provides the underlying basis for understanding how the tasks presented in this document enable Access Manager to handle the specified security issues.

Access Manager provides Single Sign-On (SSO) and Cross Domain Single Sign-On (CDSSO) features, enabling users to seamlessly authenticate across multiple web-based applications. Access Manager is able to provide this seamless authentication by using hypertext transfer protocol (HTTP) or secure hypertext transfer protocol (HTTPS) to set session cookies on users' browsers.

The way Access Manager is configured influences the way it sets the session cookies. Prior to the implementation of the tasks outlined in this document, Access Manager sets session cookies for the entire domain. Therefore, all applications hosted on the domain share the same session cookies. This scenario could enable an untrusted application to intervene and gain access to the session cookies. Specific configuration steps presented in this document address this issue. After you perform the configuration, Access Manager prevents different applications from sharing the same session cookies.

The following list provides some details about possible security issues related to session-cookie hijacking (labels, such as “Security Issue: Insecure Protocol,” are used to make the issues easy to identify and discuss):

Security Issue: Insecure Protocol: An application does not use a secure protocol, such as HTTPS, which makes the session cookie prone to network eavesdropping.

The following security issues could apply if you do not perform the tasks presented in this document.

Security Issue: Shared Session Cookies: All applications share the same HTTP or HTTPS session cookie. This shared session-cookie scenario enables hackers to intervene by using an untrusted application to hijack the session cookie. With the hijacked session cookie, the untrusted application can impersonate the user and access protected web resources.
Security Issue: A Less Secure Application: If a single “less secure” application is hacked, the security of the entire infrastructure is compromised.
Security Issue: Access to User Profile Attributes: The untrusted application can use the session cookie to obtain and possibly modify the profile attributes of the user. If the user has administrative privileges, the application could do much more damage.

Figure 1 illustrates a typical Access Manager deployment within an enterprise. While the figure helps to define security issues related to cookie hijacking, it also helps to define the solution. Therefore, the figure applies to a deployment where the tasks presented subsequently in this document have already been performed.

The deployment illustrated in the figure uses SSO. Moreover, as part of the solution, the Access Manager implementation of CDSSO is enabled. To guard against potential threats posed by cookie hijacking, CDSSO enablement is required regardless of the number of domains involved. Having CDSSO enabled when the deployment involves a single domain might seem counterintuitive, but ultimately security is increased by taking advantage of the CDSSO framework. For other information about the use of CDSSO in this type of deployment, see Enabling Access Manager to Use Unique SSO Tokens.

The numbers in the figure correspond to the numbered explanations that follow. The explanations combine to provide an outline of the process that takes place when a request is made for a protected resource, emphasizing how the SSO token flows between components. The deployment includes a single virtual AuthN (Authentication) and AuthZ (Policy) server (denoted as Access Manager or Identity Provider in the figure), and a number of applications (Service Providers), denoted as Trusted Application and Untrusted Application in the diagram. The Service Providers are usually front-ended with an agent (specifically, an agent from the Policy Agent 2.2 software set) that handles the SSO (AuthN) and Policy (AuthZ).

Figure 1 The Role of the Session Cookie in Allowing Access to Protected Web Resources

The figure demonstrates the flow of the SSO token in
processing a request to access a protected resource.

Note –

Figure 1 does not include every detail involved in the flow of the SSO token. The figure provides a simplified view that corresponds to the scope of this document.

The user accesses an application through a web browser. The agent, which is an agent from the Policy Agent 2.2 software set, intercepts the request and checks for the user's privilege to access the application. The check is specifically a check for a valid Access Manager SSO token, which is set as a session cookie in the user's browser.
Assuming the user does not have a valid SSO token, the agent redirects the browser to Access Manager Authentication Service. The agent also provides its identity using the Liberty AuthN request specification. Since this single redirection is a two step process, it is illustrated in the figure as two substeps: 2A and 2B.
Access Manager Authentication Service authenticates the user and, after successful authentication, redirects the user back to the target application with the SSO token as part of the URL query parameter (in a format specified by Liberty AuthN response specification).
The agent receives a successful AuthN response from Access Manager Authentication Service. It gets the SSO token and sets it as a session cookie for the host (rather than for the domain) to the browser's request.
The agent validates the SSO token with Access Manager Session Service.
After a successful SSO token validation in Step 5, the agent then checks the permissions for the user to access the application with Access Manager Policy Service.
If permission is granted in Step 6, the user is allowed access to the application.
As indicated in the figure with an incomplete connection to Untrusted Application, the same SSO token cannot be used to gain access to an untrusted application. Access Manager denies such access since the SSO token is unique to the application and may not be shared or reissued to other agents or applications.