Tuesday, October 26, 2010

APAR Installation| How to do it efficiently and reduce downtime

Generally lot of clients bring down all servers as a part of the APAR\Code installation.

There is an alternate approach that would help a lot with down time.

As most of our APAR’s could be only commerce code changes this would work perfectly, if there are DB changes this approach may or may not work and the APAR might need analysis to see the nature of the DB changes.


1. Bring down the primary node. (Each cluster has only 1 primary node and the rest are federated nodes.)
2. The site is technically still up and should be able to handle the requests.
3. Install APAR using the DM on the primary node. (All the APARs are technically always installed only primary node.)
4. Verify for successfully installation of the APAR.
5. At this point bring down other nodes.
6. Synchronize nodes and restart.

It takes about 15 minutes to do the step 5 and Step 6 and that should be the down time.

Also the same approach is used for code deployment and apparently this helps them to confirm for the code deployment and if there are issues with any code deployment, the site can still be up while the issue is worked upon.

More Information on the topology look up in info center:

IBM has APARs, Fix Packs and Feature packs for Commerce and Fix Packs and iFixes for Application Server.

Topology Background high level: IBM 6.0 Deployment: Cell\Nodes\Node Agent\DM (Network Deployment Manager)

Sunday, October 17, 2010

Why use Ajax? Using Ajax for performance reasons

AJAX is a very powerful tool to the web world and adds another dimension to the eCommerce pages.

I have used this mainly:

1. For interactive or dynamic interfaces on the web.

2. To bypass the akamai cached pages for dynamic content. If you are not using partial caching for akamai pages. It is a very powerful tool for pricing\ATP Messaging in product and category pages.

3. For performance improvements. e.g. Accessories in a cart. As these events can be asynchronous and does not have to wait for the whole page to load up.

Out of the box DOJO is provided and I have used RICO for several years, when we did the comparisons at that time, it was strictly for performance reasons that RICO was chosen. And JQUERY seems to be the preferred choice now a days.

I have used primarily for?

1. Replace the complete DIV\SPAN as AJAX response.

2. Use JSON in the Ajax response to replace selected HTML elements.

Things to do for an Ajax call to work.

1. Register the Ajax event.

2. Write the custom controller command for the Ajax and register command and response in struts-config-ext.xml

3. Ajax response JSP to replace the HTML entity.

I have found it particularly interesting to use AJAX for performance for min-carts\Accessories and other places where the complete page reload can be avoided.

Saturday, October 16, 2010

OWASP TOP 10, How WCS OOB addresses these vulnerabilities or provides frameworks to help.

The goal of this blog is to explain how the OWASP top 10 are protected in WCS out of the box.

OWASP (Open Web Application Security Project)is used to educate web application architects\developers\testers\managers regarding the most common security vulnerabilities.

Always abide these common security principles:
Accept known good.
Default Deny.
Principle of least privileges.
Using Layered Security or Defense in Depth.

The OWASP Top 10 is a list updated by OWASP every year of the top 10 security risks.

A1 - Cross Site Scripting (XSS)
A2 - Injection Flaws
A3 - Malicious File Execution
A4 - Insecure Direct Object Reference
A5 - Cross Site Request Forgery (CSRF)
A6 - Information Leakage and Improper Error Handling
A7 - Broken Authentication and Session Management
A8 - Insecure Cryptographic Storage
A9 - Insecure Communications
A10 - Failure to Restrict URL Frequently,

A1: XSS is caused by vulnerabilities such as introduce worms,hijack sesssions, etc in the sites that allow user supplied data that is not encoded and validated properly.

WCS Protection:
In wc-server.xml starting the XSS could be specified at every module
and prohibited characters can be specified in the list.
It is a good to have a whilte list for input validation and there is a black list in wc-server.xml for restricting.
enabled="true" name="Cross Site Scripting Protection">
<ProhibitedAttrs display="false"/>
<ProhibitedChars display="false">
display="false" name="&lt;SCRIPT"/>
display="false" name="&lt;%"/>
display="false" name="&amp;lt;%"/>
display="false" name="SCRIPT>"/>
display="false" name="&amp;lt;SCRIPT"/>
display="false" name="JAVASCRIPT:"/>
display="false" name="&amp;#x73;&amp;#x63;&amp;#x72;&amp;#x69;&amp;#x70;&amp;#x74;"/>

it provides the input validation framework that can be used to validate the input text by regular expressions.

In JSP you can use the UIUtil to validate:
<%@page import="com.ibm.commerce.tools.util.UIUtil"%>

It is always recommended to validate data on the server side, client side validation can be broken by hackers.

A2 - Injection Flaws could result in is caused modifying, deleting or viewing unauthorized data.when user specified data is passed to SQL interpreter as a command.

WCS Protection:In WCS and J2EE in general using prepared statements with specific parameters and validating the parameters is a generally used practice.
Dynamic query front end should be minimized for customer facing applications.

A3 - Malicious File Execution could result in server compromise and virus attacks and this is caused by Remote file inclusion and remote code execution that allows applications to accept files that could result in include hostile files and data.

WCS Protection: WCS being a J2EE App is executed in a JVM run by a sandbox protected by a security manager. It is very important to configure the security manger and the app is demanding permissions appropriately.
Strong user input validation helps even this vulnerability.
Firewalls for web servers should be protected and have a exact or a whitelist of ports and IP addresses that it can allow connections from.
At the OS level, a good idea to segment the file system in production and having an appropriate demarcation.

A4 - Insecure Direct Object Reference could cause unauthorized access to data and files hosted in a web application and this is caused by having direct references such as file, directory, a database key such as orderId, userId exposed in the web application html code or cookies.

WCS Protection:: It has Access controls in place for protection when exposing database keys OrderId,UserId..etc. It has a cookie WC_AUTHENTICATION_148499839 and the value is appended with a uniquely generated code.
Access controls for commands and views are protected in commerce by a ACPolicy.xml and all custom commands\views\resources should be correctly defined in these files.

A5 - Cross Site Request Forgery (CSRF): It could compromise the authorized users data and using his credentials exploit other system vulnerabilities as an authorized user. This is mainly caused by remotely taking control of user's session and forging requests from the victim's browser.
XSRF could use the XSS vulnerability to exploit other system vulnerabilities.
Each request a valid unique token that is passed back and forth.

WCS Protection: WCS offers out of the box protection against this vulnerability starting with WCS FixPack
Please find below the configuration and code required to address. The action needs to be updated in struts-config-ext.xml with csrfProtected attribute.

<action parameter="com.ibm.commerce.usermanagement.commands.UserRegistrationUpdateCmd" path="/UserRegistrationUpdate" type="com.ibm.commerce.struts.BaseAction"><set-property property="https" value="0:1"><set-property property="authenticate" value="0:0">
<set-property property="csrfProtected" value="10101:1">
# Edit the JSP file that invokes this action to include the authToken URL parameter.
For example:
<input name="authToken" value="${authToken}" id="WC_UserRegistrationUpdateForm_FormInput_authToken_In_Register_1" type="hidden">

Do use HTTP Post when sending sensitive data.
WCS also has configurable transaction LoginTimeout in wc-server.xml.

A6 - Information Leakage and Improper Error Handling: It could result in powerful attacks and the web application details such as configuration information, internal workings, etc can be leaked via html outputs or long error messages

WCS Protection: Out of the box provides ECApplicationException and ECSystemException and it allows all the errors generated to be forwarded to a common view.
The detailed messages can be disabled and commerce provides a framework to define user friendly messages for these exception using ECMessage and ECMessageHelper.
Making sure all the coders follow the common exception flow handling.
Also if you are using custom logging framework make sure all the sensitive data is masked in the logs.
This framework and exceptions can be extended to incorporate custom features. Some websites also tend to send the user back to home page on any system exception.

A7 - Broken Authentication and Session Management, this vulnerability could lead to breaking into user\admin passwords and also violating privacy laws. This is caused by flaws in authentication mechanisms and poor session management.

WCS Protection: It uses one way hash for the password protection and it protects the passwords from being decrypted.
WCS Commerce admin console provides an interface to define password policy and account policy and this policy is configurable and can be modified on a periodical basis.
WCS allows configuration using struts configuration to define URL's that require authentication.
WCS uses secure authentication cookie (WC_AUTHENTICATION_ID) to manage authentication data
All administrative functions are hosted on applications such as Accelerator\Admin Console\Org admin console and these are open on ports 8000,8002,8004. These ports should not be open to internet and all these users who have access to these internal applications should be governed by good password and account policies just like external users.

A8 - Insecure Cryptographic Storage
This could lead to compliance violations such as PCI and also sensitive data such as credit card information could be leaked. This is mostly caused by weak cryptographic algorithms and the key management.

WCS Protection:
WCS uses strong triple DES algorithm for encryption. That meets the PCI DSS standards.
WCS also provides KLF framework to change the encryption key periodically and allows to re encrypt the sensitive data using the new key.
Do not create new cryptographic algorithms use standard API e.g. bouncycastle.
Store private keys with extreme care.

WCS out of the box introduces keyword krypto on protected sensitive information.

e.g. Out of the box in wc-server.xml
<ProtectedParameters name="Protected Parameters">
<Parameter display="false" name="cardNumber"/>
<Parameter display="false" name="password"/>
<Parameter display="false" name="passwordVerify"/>
<Parameter display="false" name="passwordOld"/>

Also there are 2 other elements that should be defined appropriately ProtectedMultiValuedParameters and NonEncryptedParameters

A9 - Insecure Communications
This would result in compliance failures and could expose the private data for spoofing.
This is resulted from not using encrypted network traffic. Opening your webservers to a limited blacklists of Port and IP Addresses.

WCS Protection:
Using SSL when transmitting sensitive data can be achieved by configuring the corresponding actions and views
<set-property property="authenticate" value="0:1"/>
<set-property property="https" value="0:1"/>

For back end applications communicating with external applications, make sure the firewall is opened for specific IP Addresses any communication required.

A10 - Failure to Restrict URL Frequently, could result in exposing a certain function or data to unauthorized users. This could be resulted from not having access control checks to protect resources\urls

WCS Protection: out of the box offers access control mechanism and also roles for segmenting authorized content. The access control matrix should be included as a apart of the design and development and URL's and Actions are appropriately protected.

The access control framework: It divides Views and Commands that require authentication and authorization is handled by the access control policies.

This was the list from earlier to 2010.

2010 has a couple more vulnerabilities

Unvalidated Redirects and Forwards

Add a URLRedirectFilter element in the Module element as shown in the following example:
<module contextpath="/webapp/wcs/stores" fileservletenabled="false" name="Stores" urlmappingpath="/servlet" webalias="/wcsstore">
<initparameters adapters="XML/HTTP, BrowserAdapter" contextsetname="Store" handledoubleclick="true">
<urlredirectfilter enable="true">
<allowedhost name="www.mycompany1.com">
<allowedhost name="www.mycompany2.com">
<alloweddomain name="mycompany3.com">

A6: Security Misconfiguration :

Applying the latest patches at OS\DB\Application server and Commerce server and making sure the security configuration is correctly done.


Tuesday, October 5, 2010

DB Clean | performance of overall site

DB Clean:
In my opinion next to Dynacache\EdgeCaching strategies for a site. I would consider DB Clean a very important aspect of improving site performance for WCS. It would also prevent any junk car issues.

Out of the box, commerce provides a table for adding these queries CLEANCONF table, which is good enough for most basic queries for complex cleanup operations, it is very important to use store procedures.

High Level commerce deletes required for
1. Address
2. CtxMgmt
3. Guest users
4. Orders
5. Schedulers
6. Staglog
7. CustomData

values (
'activity', 'remove-obsolete-ctxmgmt',
'delete from ctxmgmt where lastaccesstime < (sysdate - ?)',
'no', 1, 'yes');

Crontab utility in unix/solaris can be used to schedule these jobs. Usually it is very important to wrap this in a shell script and use some logging and also capture the PID, if you need to kill a process.