In the PART1 of this series, I introduced the topic of security around eCommerce from a perspective of being in a Hot Air Balloon (which would be 2000 lifetime floor badge if you wear a Fitbit). You will want to read the Part 1 to get a glimpse of CISO’s role in your organization’s security, and introduction on IBM’s security services. However, if you want to directly dive into securing your WebSphere Commerce application, read on this article.
The WebSphere Commerce security model constitutes of setting up the access control, through authentication, authorization and policies. It provides through some of the main security standards applicable to the eCommerce industry. It also covers managing against common attack types. However, as outlined in the PART 1, the malicious attacks continuously innovate themselves, and therefore business needs to evaluate its advanced threat management capability on an ongoing basis.
In this PART2 of the series, I am going to cover 4 areas from the application perspective.
- Access control
- Hardening against common attacks types
- Data security
- Security Standards
Authentication: WebSphere Commerce issues an authentication token. This token is associated with a user on every subsequent request after the authentication process. There are account policies for password, account lockout, timeout that govern authentication.
Authorization: Access control policies is leveraged for enforcing authorization in Commerce.
Let us look at some some common access control areas that are prominent from en eCommerce perspective.
- Logon - Enforcing too many failed attempts: Set up an account lockout policy for different user roles in WebSphere Commerce. This is to enable enforcement of a lockout in case there is malicious attempt to break a password. There is also deterrents by setting up delays in between of consecutive unsuccessful attempts.
- Logon - Prevent privileged users from logging in externally: It is desirable to dis-allow access to the privileged users of WebSphere Commerce application, like the site administrator or a customer service representative. This need is primarily from a security perspective where one would not want a hacker to gain privileged access and act with malicious intent. WebSphere Commerce V 8 Mod Pack 1 has provided with a security configuration in wc-server.xml that can be enabled and then customer headers can be used to define roles to disallow the logon. There is further customization that one can do to address the security needs for logon. Earlier to this introduction of the feature, in earlier version of WebSphere Commerce (v7, v8), the article provides sample code to achieve the functionality.
- Securing the WebSphere Commerce search server: This can be achieved at two levels, WebSphere Application Server (WAS) Administrative Security or WebSphere Application Server (WAS) Application Security. The WAS Admin Administrative Security is recommended, as the application security is more expensive in terms of performance.
Protecting custom enterprise beans, data beans, controller commands, views: Primary resources should be protected. If a user is allowed to access a primary resource, the user would be allowed to access its dependent resources.
Access Control and Data Beans - The following article discusses the best practices for access control with WebSphere Commerce and how to use Data Beans securely
Hardening against common attacks types - A view on the common attacks types and guidance on handling them
- Changing URL params to break the system: WhiteList data validation on a URL is disabled by default. This restricts the running of URL such that it only allows processing of URLs that conform to the regular expression. This means you could restrict any malicious intent on the site by changing the params on the URL for store-id, catalog-id etc...
- Cross-site scripting protection, is enabled by default for the Stores web module. It is important that all the parameters are encoded by developers during the development phase and tested thoroughly. The prohibitedChars rule has been provided by default, however it cannot be comprehensive. The blacklist is used as fall back for cases when the store is not encoding the output properly (c:out). The problem with blacklists is that hackers keep finding ways of bypassing them by using different encodings and escaping characters. It's not possible to come up with a completely robust blacklist solution ( OWASP calls blacklist "fragile" ). This is more complex to apply to the REST body. It is recommended that there is a review on the OWASP Cross-site Scripting site for project implementation. The project management and security architect should provide guidelines on preventing, protecting and testing against Cross-site scripting.
- Mitigating threat of denial of service attacks: It is recommended to set the boundary for the product search results by specifying maximum page size and result size. Similarly, one can set allowable ranges for other business objects like the shopping cart.
- Enable ClickJacking Protection – Clickjacing is when an attacker is able to trick you into believing that you are on a particular site/page, while re-directing you to do something else. This can be achieved via several techniques, however we will focus on the mechanism where iFrames are exploited to overlay your desired site. The article talks about the X-Frame options and Content Security Policy.
- WebSphere Commerce database encryption to a stronger standard to reduce the chances of a successful brute force attack by Migrating from Triple DES to AES-128 encryption
- Data security practices for integrating eCommerce system with Order Management System
1 - Use of Cryptographic Algorithms and Key Lengths: NIST announced its Special Publication (SP) 800-131A in 2011, which recommends transitioning of the use of Cryptographic Algorithms and Key Lengths.
Standard requires adherence to
- Digital signatures must use at least SHA-2 hashing algorithm, and WebSphere Commerce v8 uses SHA-2
- Cryptographic keys adhere to a minimum key strength of 112 bits. WebSphere Commerce provides a detailed procedure for the migration of encrypted data in the database to use AES 128-bit encryption.
- Enable TLS 1.2 for SSL and disable protocols less than TLS 1.2 for WebServer, any integrations with LDAP, outbound email. WebSphere Application server must adhere to TLS 1.2
- All certificates with RSA or DSA keys must be 2048 bits or higher. Certificates with elliptic curve keys shorter than 160 bits must be replaced with longer keys. All certificates must be signed by an allowed signature algorithm. For example, SHA-256, SHA-384, or SHA-512
2 - Federal Information Processing Standards publication 140-2 (FIPS 140-2) covers the security standards that are required for cryptographic modules. The WebSphere Commerce documents the steps that are needed for commerce to runn on a WebSphere Application Server and on HTTP servers that are in FIPS 140-2 mode.
3 - The Payment Card Industry (PCI) Data Security Standard (DSS) - The PCI DSS Version 3.0 standard lists 12 requirements which retailers, online merchants, credit data processors, and other payment-related businesses must implement to help protect cardholders and their data. The requirements include technology controls (such as data encryption, user access control, and activity monitoring) and required procedures. This is required to be implemented when the cardholder data resides with the business. The WebSphere Commerce Knowledge Center documents the procedure ONLY for the WebSphere Commerce application to be PCI compliant, while there are many other aspects that the business needs to take care as part of the compliance.
The security of eCommerce is a broad topic that requires the Chief Information Security Officer (CISO) at the organization to work at various levels. This was covered in the PART 1
This article is an attempt to help the reader get a glimpse on the application security aspects for a commerce site. I have tried to categorize security from a view of access, vulnerabilities and data protection and help with a capability view on WebSphere Commerce.
I have also created a template spreadsheet that one can refer in their project as a starting point to track the various headings, status and desired status. This template is to be enhanced/tailored to suit your security posture.