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 6.0.0.4 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.
e.g.
<XSiteScriptingProtection
display="false"
enabled="true" name="Cross Site Scripting Protection">
<ProhibitedAttrs display="false"/>
<ProhibitedChars display="false">
<Character
display="false" name="<SCRIPT"/>
<Character
display="false" name="<%"/>
<Character
display="false" name="&lt;%"/>
<Character
display="false" name="SCRIPT>"/>
<Character
display="false" name="&lt;SCRIPT"/>
<Character
display="false" name="JAVASCRIPT:"/>
<Character
display="false" name="&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;"/>
</ProhibitedChars>
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"%>
<%=UIUtil.toJavaScript(java.lang.String.valueOf(pageContext.getAttribute("storeId")))%>
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.
148499839%2csFggXZ6m06QiSRLRI9c8DuYlQPc%3d
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 6.0.0.8.
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">
</set-property>
# 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"/>
</ProtectedParameters>
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
e.g.
<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 vulnerabilitiesA10:
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">
</alloweddomain>
</allowedhost>
A6: Security Misconfiguration :
Applying the latest patches at OS\DB\Application server and Commerce server and making sure the security configuration is correctly done.
ref:
http://www.owasp.org/index.php/Main_Page
