WebSphere Portal relies on setting certain cookies to enforce its security controls. As an administrator, you should carefully consider how to protect these cookies in your environment. Unauthorized parties could circumvent WebSphere Portal's security controls given access to:
LTPAToken2 (and LTPAToken, if Interoperability Mode is enabled): Lightweight Third-Party Authentication: WebSphere Application Server relies on this cookie for Single Sign-On. WebSphere Application Server considers a client to be authenticated if it presents a valid LTPAToken2.
JSESSIONID: from the Java Servlet specification: WebSphere Portal's session management uses this cookie.
1. To guard against network eavesdropping, enable SSL for all communications between the browser and the web server. Without an HTTPS pipe, you are relying on the security of the network (which could be a valid option in intranet or VPN environments). If you cannot guarantee network security, it is essential that these cookies be transmitted only within an HTTPS pipe.
2. Define these cookies' domains as narrowly as possible. If a cookie's domain is left unset, the browser should present it to only the server that set the cookie.
3. In conjunction with (1) and (2), consider setting the secure attribute on these cookies. For example, a browser accesses https://portal1.ibm.com/wps/myportal, authenticates, and LTPAToken2 is set with domain=ibm.com. When the browser later requests http://server2.ibm.com, it presents LTPAToken2 over HTTP because of the domain. Setting the secure attribute tells the browser to present the cookie only over HTTPS, regardless of domain.
4. Set HTTPOnly to guard against cross-site scripting (XSS). When HTTPOnly is set for a cookie, the browser should not allow scripts to access the cookie. Of these several recommendations, this is the most highly reliant upon browser implementation. HTTPOnly is a useful tool, but application developers should be vigilant in guarding against XSS regardless of HTTPOnly.
5. Consider your securtiy requirements when configuring LTPA token expiration and session timeouts. Expiration is actually encoded into an LTPA token's value. Simply restricting access to the server long enough for all issued LTPA tokens to expire would mitigate a known breach.
Note: If WebSphere Portal is integrated with an external security manager (ESM) in your environment, you might also need to consider the ESM's cookies. For example, given a valid ESM cookie, a trust association interceptor could instruct WebSphere Application Server to issue a new LTPAToken2.
For more information on these and other WebSphere Portal security topics, refer to: