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:
| Task | Resources |
|---|---|
| Configure the 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 This flag ensures the session cookie is only transmitted over HTTPS channels such that the session cookie is not carried over insecure HTTP redirections. | |
| Choose a Session Cookie Name Change the name of the session cookie from the default of | "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".