Enablement and migration considerations of Security hardening features
With WebSphere Application Server v8.0, more security hardening features of the server are enabled by default. When migrating, the settings enabled before the migration are retained. To ensure the configuration is set to be secure by default, the following defaults have been changed as part of the new security hardening features in WAS v8.0:
- Enablement of SSL-required on CSIv2 transport by default
The following settings for the CSIv2 transport layer exist:
- TCP/IP for a TCP/IP connection
- SSL-supported for a TCP/IP or an SSL connection
- SSL-required for an SSL connection only
SSL-required is the new default in this release of WAS. Switching to SSL-required as the default setting ensures that all CSIv2 connections into and out of the server are using the secure SSL connection.
- Enablement of the HttpOnly attribute on LTPA cookies by default
When custom property...
com.ibm.ws.security.addHttpOnlyAttributeToCookies custom = true
...the HttpOnly attribute is added to those security cookies (LTPA and WASReqURL cookies) created by the server. The HttpOnly attribute is a browser attribute created to prevent client side applications (such as Java scripts) from accessing cookies to prevent some cross-site scripting vulnerabilities. This attribute is now configurable in the console. Before WebSphere Application Server Version 8.0, the com.ibm.ws.security.addHttpOnlyAttributeToCookies custom property default was false. For WebSphere Application Server Version 8.0, the default is now true for both the LTPA cookie and the Session Cookie.
- Enablement of session security integration by default
Only authenticated users can access sessions created in secure pages. The session management facility uses the security infrastructure to determine the authenticated identity that is associated with a client HTTP request, and either retrieves or creates a session. For more information on session security, read the Session security support article.
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. For more information on credential persistence, see the "Use available authentication data when an unprotected URI is accessed" feature in the web authentication settings article.
Enable the new security hardening features after migration
If the new security features are not enabled after migration, we can enable them yourself using the console or by scripting.
- Enablement of SSL by default on CSIv2
- To enable SSL by default for inbound and outbound transports on CSIv2:
For the console, select...
Security | Global security | RMI/IIOP | CSIv2 inbound communications
In the Transport box, select SSL-required from the pull-down list and then click Apply.
Repeat the same steps for CSIv2 outbound communications and click Security > Global security > RMI/IIOP > CSIv2 outbound communications. In the Transport box, select SSL-required from the menu list and then click Apply.
To enable SSL by default for inbound and outbound transports on CSIv2 by, use the configureCSIInbound and configureCSIOutbound commands.
For the client side, edit the sas.client.props file. Change com.ibm.CSI.performTransportAssocSSLTLSRequired to true and change com.ibm.CSI.performTransportAssocSSLTLSSupported to false.
- Enablement of the HttpOnly cookie attribute
- To enable the HttpOnly attribute on cookies by default:
For the console, click...
Security | Global security | Custom properties | New
...and set...
com.ibm.ws.security.addHttpOnlyAttributeToCookies = true
We can also enable the HttpOnly attribute using the console by clicking...
Security | Global security | Single sign-on (SSO)
To help prevent cross-site scripting attacks, and click...
Set security cookies to HTTPOnly
To enable the HttpOnly attribute on cookies by default, use the command...
setAdminActiveSecuritySettings command
- Enablement of session security integration
- To enable session security integration for each server using the console, select...
Servers | Server types | WebSphere application servers | server1 | Session management
Select the security integration check box.
To enable persisting credentials from the console, click...
Security | Global security | Web and SIP security | General settings
Select the Use available authentication data when an unprotected URI is accessed check box.
Security hardening features enablement troubleshooting
When the new security hardening features are enabled, you might see some differences in system behavior depending upon which environment we might have used in the past.
For example, if you are coming 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. Read about the Secure communications using SSL topic for more information.
If we worked in an environment where TCP/IP is used for the connection to CSIv2, you 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 you 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 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 you 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 that is experiencing the problem.
Related concepts
Secure communications using SSL
Related tasks
Configure Common Secure Interoperability authentication Tuning, hardening, and maintaining security configurations
Session security support Security custom properties Web authentication settings