This is a guest post written by Ben Carlson, the Director of Managed Services at Amplifi Commerce. Spark::red Team would like to thank Ben for sharing this valuable information with our readers.
Oracle Commerce’s runAssembler tool overrides context.xml customizations; here’s how to fix it.
Overview
Recently one of our clients hired a security firm to run a security and vulnerability scan on their web applications which we manage and maintain. The results were pretty good. There were a few issues of varying severity, one of which was an HttpOnly cookie vulnerability. I’m going to talk about what we did to resolve this issue for our customer.
The Open Web Application Security Project (OWASP) describes the issue: “HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client-side script accessing the protected cookie.” “If the HttpOnly flag is included in the HTTP response header, the cookie cannot be accessed through client-side script. As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser will not reveal the cookie to a third party.”
While it’s a common issue, not all browsers are vulnerable, and not all browsers support or respect the HttpOnly cookie, specifically, Opera and IE have various weaknesses. That being said, our client felt the fix was important enough for us to spend time on.
The Setup
Our client is using the JBoss 5. x application server for their Oracle Commerce application, but the solution we came up with should work for Weblogic and Websphere as well, as it’s a standard J2EE web application. After researching the issue, we determined the best solution was to modify the context.xml file in each public-facing .war file.
The problem is, the Oracle Commerce runAssembler utility ignores any custom context.xml files that are placed in the WEB-INF directory in your source code, and instead deploys a default file similar to:
<?xml version=”1.0″ encoding=”UTF-8″?>
<Context cookies=”true” crossContext=”true”>
<SessionCookie path=”/”/>
</Context>
When what we really want is more like:
<?xml version=”1.0″ encoding=”UTF-8″?>
<Context crossContext=”true” cookies=”true”>
<SessionCookie path=”/” secure=”true” httpOnly=”true”/>
</Context>
Solution
After doing some research, it was determined that we could add the line:
<SessionCookie secure=”true” httpOnly=”true” />
to the $JBOSS_HOME/jboss-as/server/<instance>/deploy/jbossweb.sar/context.xml file, and it would apply the required change to all .ear files in that server instance. After testing, however, it was found that the context.xml file in the WEB-INF directory of the .war would override this.
After doing some testing, we were able to verify that removing the context.xml file from the WEB-INF of the .war would allow the jbossweb.sar/context.xml file to be active, and the application would run properly.
At Amplifi, we primarily use http://ant.apache.org‘”>the Apache Ant build tool to compile, test and assemble Oracle Commerce web applications into a .ear file for deployment. The sequence of events in our standard build script is to compile the code, generate the custom modules into the $ATG_ROOT directory, then runAssembler and generate the ear files into the $JBOSS_HOME/server/<serverInstance>/deploy/ directory. Due to the runAssembler command running last, we have to remove the context.xml file in the required .war files within the generated .ear directory (or .ear file, as the case may be).
In our ant build.xml file, we added a delete command:
<delete>
<fileset dir=”${ear.todeploy.destination}/${ear.todeploy.filename}”>
<include name=”**/WEB-INF/context.xml”/>
</fileset>
</delete>
Servlet spec 3.0 Containers
As I mentioned before, this client is using JBoss 5.x, however newer versions of Oracle Commerce support newer Servlet containers. Instead of taking the outlined approach, if your Servlet container supports the 3.0 spec, you can add the following to your web.xml file:
<?xml version=”1.0″?>
<web-app xmlns=”http://java.sun.com/xml/ns/javaee”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee web-app_3_0.xsd”
version=”3.0″>
<!– Make sure that your web.xml is pointing the version=”3.0″ as above –>
<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>
</web-app>
Testing
In Chrome, if you use the developer tools, you can go into the “Resources” tab, and open the “Cookies” tree node. Under this node, you’ll see at least one hostname; the server to which you’re making requests. Prior to making the change, you’ll see the JSESSIONID=XXXXXXX cookie. After making the change, you’ll no longer see the cookie.
In order to further validate the fix, with the fix applied, open the Chrome “Settings” menu, select “Show advanced settings”, and click on the “Content settings…” button. This will open a modal window; click the “All cookies and site data” button, and search for your hostname. You’ll find a JSESSIONID cookie. Click on it. Inside you’ll see:
Accessible to script: No (HttpOnly)
This means that the context.xml change has been successfully applied.