Securing the Session Cookie

After authenticating an end user, AM stores their session (for client-based sessions), or a pointer to their session (for CTS-based sessions), in a cookie in the end user's browser.

HTTPS communication already helps to keep cookies secure since the encrypted communication cannot be eavesdropped. However, there are other ways a malicious user can hijack a cookie. For example, cross-site scripting (XSS) and cross-site tracing (XST) involve injecting HTML or JavaScript on a legitimate website. By using JavaScript code, the malicious user can steal the cookie directly from the browser.

The following table summarizes the tasks you need to perform to protect session cookies:

TaskResources

Configure the HttpOnly Flag

This flag ensures that the session cookie is transmitted over an HTTP or HTTPS channel only, protecting your environment against most XSS attacks.

"Configuring HttpOnly Session Cookies"

Configure the secure Flag

This flag ensures the session cookie is only transmitted over HTTPS channels such that the session cookie is not carried over insecure HTTP redirections.

"Configuring Secure Session Cookies"

Choose a Session Cookie Name

Change the name of the session cookie from the default of iPlanetDirectoryPro.

"Changing the name of the Session Cookie"

Restrict CDSSO Tokens to protect them against hijacking

By default, AM provides a CDSSO tokens valid for the appropriated realms. Restrict tokens so that AM issues different tokens for different realms.

"Enabling Restricted Tokens for CDSSO Session Cookies"

Use host-only cookies

Because host-only cookies are more secure than domain cookies, you should use host-only cookies unless you have a good business case for using domain cookies.

Cookie Domains

Tip

Client-based sessions are more vulnerable to hijacking, since they contain all the session information. To configure additional security measures, see "Configuring Client-Based Session Security".

Read a different version of :