About Cookie Hijacking Prevention

A common concern for administrators who want to restrict access to web-based applications in an OpenSSO Enterprise deployment is that hackers might use rogue or untrusted applications to steal, or hijack, session cookies. The way OpenSSO Enterprise is configured influences the way it sets the session cookies. By default OpenSSO Enterprise sets session cookies for the entire domain. 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, which in turn poses a security threat. To guard against potential threats posed by cookie hijacking, configure CDSSO with cookie hijacking prevention. As a best practice, configure CDSSO with cookie hijacking prevention even in the deployments where all OpenSSO Enterprise components are in same domain. Having CDSSO and cookie hijacking prevention enabled when the deployment involves a single domain may seem unnecessary. But ultimately security is increased by taking advantage of both features.

Key Cookie Hijacking Security Issues and Solutions

The term “cookie hijacking” refers to a situation where an impostor gains unauthorized access to cookies. The imposter could be a hacker using an untrusted application. 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.

Shared Session Cookies Security Issue

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.

OpenSSO Enterprise Solution

Unique SSO token is issued to each application or policy agent after the user has been authenticated. The unique SSO token is referred to as a "restricted token." The restricted token is inextricably connected to the application and to the policy agent. Since each user's SSO token is unique for each application or policy agent, the increased security provided by this scenario prevents an untrusted application, impersonating the user, from accessing other applications. More specifically, the restricted SSO token assigned to a user as a part of the user's session is associated with the policy agent that initiated the original redirection for authentication. So all subsequent requests are checked to verify that they are coming from the same policy agent. 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 (IP or DN) is associated with the restricted token. OpenSSO Enterprise server checks the validity of the IP or DN before performing any operation using this restricted token. From OpenSSO Enterprise 8.0 Update 1 onwards, you can configure the DN only restriction. The DN only restriction is suitable if the agents are behind the firewall. This constraint is what ensures that the restricted token is only used for an application that a given policy agent protects.

Access to User Profile Attributes Security Issue

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.

OpenSSO Enterprise Solution

By issuing a restricted SSO token, the set of Session Service operations that can be performed are limited using these tokens. This functionality enables OpenSSO Enterprise to prevent applications from modifying profile attributes of the user. The following figure illustrates a typical OpenSSO Enterprise deployment within an enterprise. While the figure illustrates security issues related to cookie hijacking, the figure also illustrates the solution.

Figure 16–4 Process Flow for Cookie Hijacking Prevention

OpenSSO Enterprise Session Cookies Involved in Issuing Unique SSO Tokens

When OpenSSO Enterprise is configured to issue unique SSO tokens for each application or policy agent, the following cookies are involved:

Table 16–1 Session Cookies in Unique SSO Tokens

Cookie Name	Place Holder Cookie Value	Domain
iPlanetDirectoryPro	SSO-token The actual cookie value is the value of the token.	The domain is set to the host name of the OpenSSO Enterprise instance where the user was authenticated.  Example:  OpenssoHost.example.com
iPlanetDirectoryPro	restricted-SSO-token The actual cookie value is the value of the token.	The domain is set to the host name of the policy agent instance for which the restricted token is issued.  Example:  agentHost.example.com
sunIdentityServerAuthNServer	https://OpenssoHost.examplecom:8080 The cookie value is the URL of the OpenSSO Enterprise instance where the user was authenticated.   In this example, the protocol is HTTPS.	The domain must be set to cover all instances of OpenSSO Enterprise installed on the network.  Example:  .example.com