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.