WAS v8 new security hardening features
As of WAS v8+ the following security hardening features are enabled by default.
- SSL-required on CSIv2 transport.
- HttpOnly attribute on LTPA cookies.
When custom property...
....the HttpOnly browser attribute is added to security cookies LTPA and WASReqURL. The HttpOnly attribute helps prevent client side applications (such as Java scripts) from accessing cookies, which helps prevent cross-site scripting. This default is for both the LTPA cookie and the Session Cookie.
- Session security integration
Only authenticated users can access sessions created in secure pages. The session management facility uses the security infrastructure to determine the authenticated identity associated with a client HTTP request, and either retrieves or creates a session. Along with enabling session security integration, credential persistence is enabled as well. This allows login information to be available to unprotected web clients to enable more access to user information. See Use available authentication data when an unprotected URI is accessed.
To enable session security integration for each server, from the administrative console, select...
Servers > Server types > WebSphere application servers > server1 > Session management > security integration
To enable persisting credentials from the administrative console, click...
Security > Global security > Web and SIP security > General settings > Use available authentication data when an unprotected URI is accessed
Enable the new security hardening features after migration
If the new security features are not enabled after migration, we can enable them ourself using the administrative console or by scripting.
- Enablement of SSL by default on CSIv2
- Using the administrative console...
Security > Global security > RMI/IIOP > CSIv2 inbound communications > Transport box > SSL-required > Apply
Repeat the same steps for CSIv2 outbound communications and click...
Security > Global security > RMI/IIOP > CSIv2 outbound communications > Transport > SSL-required > Apply
Using scripting, use the configureCSIInbound and configureCSIOutbound commands.
For the client side, edit the sas.client.props file and set...
com.ibm.CSI.performTransportAssocSSLTLSRequired = true
com.ibm.CSI.performTransportAssocSSLTLSSupported = false
- Enablement of the HttpOnly cookie attribute
- From the console:
Security > Global security > Custom properties > New
...and set...
com.ibm.ws.security.addHttpOnlyAttributeToCookies = true
To help prevent cross-site scripting attacks, go to...
Security > Global security > Single sign-on (SSO) > Set security cookies to HTTPOnly
Using scripting, use the setAdminActiveSecuritySettings command.
Security hardening features enablement troubleshooting
If we migrating from an environment where CSIv2 transport was set to the previous default of SSL-supported, we do not experience any differences, as SSL-supported communicates with both TCP/IP and SSL connections. If a problem is encountered, however, certificates might not have been exchanged correctly to enable the client and server to communicate.
In environments where TCP/IP is used for the connection to CSIv2, we might experience connection problem to the SSL-enabled CSIv2 connection. The server configuration can be modified to SSL-supported or to TCP/IP if SSL is not required.
For the HttpOnly attribute, when the attribute is added to the security cookies, the browser prevents client side scripts from accessing these cookies. In most cases this should be the default behavior to minimize cross-site scripting vulnerabilities. If there is an absolute need to allow client-side scripts to access WebSphere security cookies, and we are aware of the possible consequences, then the setting of the HttpOnly attribute can be disabled. However, the HttpOnly attribute can possibly uncover client-side scripts used to access WebSphere cookies, and can then use them even though it was not intended to do so. If this happens, the web application that enables the scripts to access the WebSphere cookies must be evaluated.
For session security integration enablement, when session integrated security is enabled we might receive an UnauthorizedSessionRequestException exception on servlets if they access a session that belongs to authenticated identities other than to the identity that currently owns the session. If we do not want this checking to occur, we can disable session security from the server experiencing the problem.
Related:
Secure communications using SSL Configure Common Secure Interoperability authentication using scripting Tune, harden, and maintain security configurations Session security support Security custom properties Web authentication settings