Application server security introduction
The application server is a critical system component upon which the Sterling Selling and Fulfillment Suite applications run.
However, unlike the operating systems and database management systems, the Center for Internet Security (CIS) currently does not have hardening benchmarks for application servers such as Oracle WebLogic or Red Hat JBoss. Security Technical Implementation Guides (STIG) or hardening checklists produced by the Defense Information Systems Agency (DISA) are written for a generic application server. Given the lack of consensus-built and publicly peer reviewed hardening checklists, IBM® at this time recommends that you work with your application server vendor for the overall hardening recommendations.
At IBM developerWorks®, experts at IBM have provided recommended hardening measures to strengthen the security of a WebSphere® Application Server environment.
- Enable only those application and web server functions that are absolutely necessary. Default server configurations often expose a wide variety of services unnecessarily increasing the risk to the system.
- Consider Transport Layer Protection controls:
- Only use secured Web communications. Enable SSL/TLS for all components of Sterling Selling and Fulfillment Suite to protect data when it is being transmitted.
- Only use strong SSL Cipher Suites - Attackers could view and modify seemingly encrypted SSL communications, resulting in a breach of confidentiality and integrity. Entire sessions could be compromised.
- Configure your application to only send cookies over a secure channel. The Secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the Secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of the cookie in clear text. This is recommended even though HTTPs is enabled.
- Consider restricting cookies to HTTP only. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).
- Disable Information Disclosure by your web server wherever possible
– Web server data or debugging information, such as web server type,
or certain HTTP error messages can be used as clues to form an attack
against your system. Web server configurations often are set to reveal
this type of information by default. Consider disabling these features:
- Disclosing web server type and version information
- Directory listing requests
- Disclosing information about invalid Directory listing requests
- HTTP OPTIONS requests
- HTTP TRACE requests