Chapter 22 Taking Precautions Against Session-Cookie Hijacking in an OpenSSO Enterprise Deployment

This chapter provides information about precautions you can take against specific security threats related to session-cookie hijacking in an OpenSSO Enterprise deployment.

A common concern for administrators who want to restrict access to web-based applications in an OpenSSO Enterprise deployment is that hackers might use applications, referred to as “rogue” or “untrusted,” to hijack session cookies. This chapter describes the threat posed by this hacking technique and provides configuration steps you can perform to guard against this threat, as described in the following sections:

• Defining Key Cookie Hijacking Security Issues

• Cookie Hijacking Security Issues

• Implementing the OpenSSO Enterprise Solution for Cookie Hijacking Security Issues

The tasks presented in this chapter apply to a deployment with the following components:

• Starting with OpenSSO Enterprise 8.0

• Starting with Policy Agent 3.0

Defining Key Cookie Hijacking Security Issues

The tasks presented in this chapter 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 chapter enable OpenSSO EnterpriseOpenSSO Enterprise to handle the specified security issues.

OpenSSO Enterprise provides Single Sign-On (SSO) and Cross Domain Single Sign-On (CDSSO) features, enabling users to seamlessly authenticate across multiple web-based applications. OpenSSO Enterprise 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 OpenSSO Enterprise is configured influences the way it sets the session cookies. Prior to the implementation of the tasks outlined in this chapter, OpenSSO Enterprise 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 chapter address this issue. After you perform the configuration, OpenSSO Enterprise 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 chapter.

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.

The figure illustrates a typical OpenSSO Enterprise 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 chapter have already been performed.

The deployment illustrated in the figure uses SSO. Moreover, as part of the solution, the OpenSSO Enterprise 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 OpenSSO Enterprise 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 OpenSSO 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 3.0 software set) that handles the SSO (AuthN) and Policy (AuthZ).

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

The previous figure 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 chapter.

1. The user accesses an application through a web browser. The agent (an agent from the Policy Agent 3.0 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 OpenSSO Enterprise SSO token, which is set as a session cookie in the user's browser.

2. Assuming the user does not have a valid SSO token, the agent redirects the browser to OpenSSO Enterprise 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.

3. OpenSSO Enterprise 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).

4. The agent receives a successful AuthN response from OpenSSO Enterprise 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.

5. The agent validates the SSO token with OpenSSO Enterprise Session Service.

6. After a successful SSO token validation in Step 5, the agent then checks the permissions for the user to access the application with OpenSSO Enterprise Policy Service.

7. If permission is granted in Step 6, the user is allowed access to the application.

8. 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. OpenSSO Enterprise denies such access since the SSO token is unique to the application and may not be shared or reissued to other agents or applications.

Cookie Hijacking Security Issues

This section explains how performing the tasks described in this chapter enables OpenSSO Enterprise to handle the security issues discussed in the preceding section, Defining Key Cookie Hijacking Security Issues.

When applications use a secure protocol such as HTTPS, the SSO Token is not visible to network snooping. This security issue is labeled “Security Issue: Insecure Protocol” in this chapter. Ensuring that all protected resources use a secure protocol is not a security measure administered using OpenSSO Enterprise, but this a very prudent security measure that you should consider implementing if it is not currently in place.

OpenSSO Enterprise Solution: Shared Session Cookies

The security issue labeled Security Issue: Shared Session Cookies in this chapter pertains to applications sharing the same HTTP or HTTPS session cookie. OpenSSO Enterprise addresses this security threat by issuing a unique SSO token to each Application/Agent after the user has been authenticated. The unique SSO token is referred to as a "restricted token."

The term “Application/Agent,” indicates that the restricted token is inextricably connected to the application and to the agent (which specifically refers to an agent from the Policy Agent 3.0 software set). Since each user's SSO token is unique for each Application/Agent, the increased security provided by this scenario prevents an non-trusted application, impersonating the user, from accessing other applications. More specifically, since the SSO token (restricted token) assigned to a user (as a part of the user's session) is associated with the agent that did the initial redirection for authentication, all subsequent requests are checked to verify that they are coming from the same agent. Thus, if a hacker tries to use the same restricted token to access another application, a security violation is thrown.

What makes the restricted token “restricted” is not related to the syntax of the token. The syntax of a restricted token is the same as that of a regular SSO token. Instead, a specific constraint is associated with the restricted token. This constraint is what ensures that the restricted token is only used for an application that a given agent protects.

OpenSSO Enterprise Solution: A Less Secure Application

The security issue labeled “Security Issue: A Less Secure Application” in this chapter pertains to the potential threat of applications that are “less secure.” With the OpenSSO Enterprise solution, if one application is somehow compromised, the hacker cannot hack into other applications.

OpenSSO Enterprise Solution: Modification of Profile Attributes

The security issue labeled “Security Issue: Access to User Profile Attributes” in this chapter pertains to the threat posed by an untrusted application modifying the profile attributes of the user. The OpenSSO Enterprise solution to this issue does not change the SSO token. The restricted SSO token is similar to the regular SSO token ID. However, the set of Session Service operations that accept restricted SSO token IDs is limited. This functionality enables OpenSSO Enterprise to prevent applications from modifying profile attributes of the user.

Key Aspects of the OpenSSO Enterprise Solution: Cookie Hijacking Security Issues

The following subsections explain some of the key or more complex aspects of the OpenSSO Enterprise solution to the cookie hijacking security issues defined in this chapter.

OpenSSO Enterprise Session Cookies Involved in Issuing Unique SSO Tokens

When OpenSSO Enterprise is configured to issue unique SSO tokens for each Application/Agent, the following cookies are involved:

Cookie Name	Cookie Value (place holder)	Example Cookie Domain Information
iPlanetDirectoryPro	SSO-token	OpenssoHost.example.com

The value of this cookie, which is represented in the preceding table with the place holder SSO-token, is the actual value of the token. The domain is set to the host name of the OpenSSO Enterprise instance where the user was authenticated.




Cookie Name	Cookie Value (place holder)	Example Cookie Domain Information
iPlanetDirectoryPro	restricted-SSO-token	agentHost.example.com

The value of this cookie, which is represented in the preceding table with the place holder restricted-SSO-token, is the actual value of the token. The domain is set to the host name of the agent instance for which the restricted token is issued.




Cookie Name	Example Cookie Value	Example Cookie Domain Information
sunIdentityServerAuthNServer	https://OpenssoHost.example.com:8080	.example.com

The value of this cookie, which is represented in the preceding table with the example URL https://OpenssoHost.example.com:8080, is the URL of the OpenSSO Enterprise instance where the user was authenticated. The protocol used for this particular example is HTTPS while the port number is a non-default example, 8080. The domain must be set such that it covers all the instances of OpenSSO Enterprise installed on the network.

Enabling OpenSSO Enterprise to Use Unique SSO Tokens

To enable OpenSSO Enterprise to issue unique SSO tokens, you must enable CDSSO. Therefore, though CDSSO is usually enabled for multiple-domain deployments, in this case, CDSSO must be enabled whether the entire deployment is on a single domain or is spread across multiple domains. In no way does enabling CDSSO for a single domain negatively affect the deployment.

The next section describes the steps required to configure OpenSSO Enterprise to prevent session-cookie hijacking from causing a breach of security.

Implementing the OpenSSO Enterprise Solution for Cookie Hijacking Security Issues

The instructions presented in this section provide a solution to the potential risks related to session-cookie hijacking as outlined in this chapter.

• About the Agent Profile

• Configuring the OpenSSO Enterprise Deployment Against Cookie Hijacking

This section also provides the other configuration steps necessary to guard web resources in an OpenSSO Enterprise deployment against the threat of session-cookie hijacking.

After you perform the tasks presented in this chapter, OpenSSO Enterprise starts enforcing restrictions on the sessions it creates. The new configuration enables OpenSSO Enterprise to more closely track aspects of each session. At that point, not only does OpenSSO Enterprise record which agent performed the initial redirection for authentication it also tracks the applications to which an SSO token has been issued. OpenSSO Enterprise uses this information to facilitate the processing of each subsequent request and to prevent unauthorized access to protected web resources.

About the Agent Profile

As a part of agent installation, each agent has its own agent profile. OpenSSO Enterprise server uses each agent's profile to help prevent cookie-hijacking related security issues. You can use the agent profile that was created as part of the initial agent installation, or if you choose, you can update the agent profile. If you choose to update the agent profile, this is the appropriate point to do so.

Configuring the OpenSSO Enterprise Deployment Against Cookie Hijacking

Though each agent has its own agent profile, OpenSSO Enterprise is not configured by default to associate an SSO token to a specific agent profile. The steps in this section enable this type of association. Ultimately, the new configuration introduces “restricted tokens” into the OpenSSO Enterprise deployment, guarding against security issues as described in this chapter.

To Configure the OpenSSO Enterprise Deployment Against Cookie Hijacking

This task description includes configuration information for agents in the Policy Agent 3.0 software set. Perform the task on every agent instance for which you want to enhance security. The best practice is to perform the task on all the agent instances in the OpenSSO Enterprise deployment. As part of the configuration of each agent instance, you must also make specific configurations directly to OpenSSO Enterprise. For this task, be prepared to access the OpenSSO Enterprise Console and a browser that can access a protected web resource.

1. Using a browser, navigate through OpenSSO Enterprise Console to the appropriate agent (J2EE agent or web agent, whichever applies) properties page that you want to configure.

2. Edit the agent properties as described in the substeps that follow:

   Notice, that you must navigate from Console tab to Console tab.

   1. Enable the property labeled Cross Domain SSO (Tab: SSO, Name: com.sun.identity.agents.config.cdsso.enable).

      Setting this property to Enabled, enables CDSSO, which is required for each agent instance since the agent will use functionality provided by the CDSSO feature.

   2. Set the property labeled CDSSO Servlet URL (Tab: SSO, Name: com.sun.identity.agents.config.cdsso.cdcservlet.url) as described in this substep.

      This property stores the URL to which you want to direct users after they log in successfully to a deployment enabled for CDSSO. A feasible setting for this property is as follows:

      https://OpenssoHost.example.com:8080/amserver/cdcservlet

   3. Click Save on the SSO page.

   4. (Conditional) For J2EE agents only, add a new value to the property labeled Custom Properties (Tab: Advanced, Name: com.sun.identity.agents.config.freeformproperties) as described in this step.

      Add the following value to the Custom Properties property:

      com.sun.identity.enableUniqueSSOTokenCookie=true

   5. Click Save on the Advanced page.

3. Restart the container that hosts the agent.

4. Add the required OpenSSO Enterprise properties as described in the substeps that follow.

   1. In the OpenSSO Enterprise Console, navigate back to the top level.

   2. Click Configuration tab.

   3. Click the Servers and Sites subtab.

   4. Click the OpenSSO Enterprise server name that you esny to configure.

   5. Click the Advanced tab.

   6. Add the properties and values as shown in the table that follows.

      Property Name	Property Value
      com.sun.identity.enableUniqueSSOTokenCookie	true
      com.sun.identity.authentication.uniqueCookieName	sunIdentityServerAuthNServer
      com.sun.identity.authentication.uniqueCookieDomain	DomainName. For example, example.com

   7. Click Save.

5. In OpenSSO Enterprise Administration Console, navigate back to the Configuration tab.

6. Select the System subtab.

7. Click Platform.

8. In the Cookie Domain list, change the cookie domain name as described in the substeps that follow.

   This step enables OpenSSO Enterprise to set host-specific session cookies instead of domain-wide session cookies.

   1. Select the default domain, such as “example.com.”

   2. Click Remove.

   3. Enter the name of the machine hosting the OpenSSO Enterprise instance.

      For example:

      OpenssoHost.example.com

   4. Click Add.

9. Ensure that the proper cookies appear in a browser as described in the substeps that follow.

   1. Use a browser to access a resource that is protected by the agent that you just configured.

   2. Check the browser's cookie settings to ensure that the three following cookies appear:

      Cookie Name	Example Cookie Value	Example Cookie Domain Information
      iPlanetDirectoryPro	SSO-token	OpenssoHost.example.com
      iPlanetDirectoryPro	restricted-SSO-token	agentHost.example.com
      sunIdentityServerAuthNServer	https://OpenssoHost.example.com:8080	.example.com