Secure session cookies
After authenticating an end user, AM stores their session (for client-side sessions), or a pointer to their session (for server-side 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. |
|
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 |
|
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. |
|
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. |
|
Client-side sessions are more vulnerable to hijacking, since they contain all the session information. To configure additional security measures, see Client-side session security. |