Skip to main content

Trustwave SpiderLabs sets sights on Mojarra, MyFaces

Posted by edburns on January 31, 2010 at 1:11 PM PST

I received an email from core Mojarra team member href="http://www.java.net/blogs/driscoll/">Jim Driscoll, who was
inexplicably laid off from Sun after its recent acquisition by Oracle,
about a talk at next week’s href="http://blackhat.com/html/bh-dc-10/bh-dc-10-briefings.html">BlackHat
Conference in Arlington, VA, U.S.A.. Jim pointed out that two
security luminaries from the elite href="https://www.trustwave.com/spiderLabs.php">SpiderLabs team from
Trustwave are giving a talk at BlackHat about view state security,
specifically focusing on Mojarra and MyFaces.

Cursory research on the talk found two articles: one by Kelly Jackson
Higgins at href="http://www.darkreading.com/vulnerability_management/security/vulnerabilities/showArticle.jhtml?articleID=222600302#community#comments">DarkReading,
and another (which appears to be based on the first) at href="http://www.scmagazineuk.com/a-malicious-use-of-view-state-that-allows-visibility-of-a-users-credentials-will-be-demonstrated-at-next-weeks-black-hat-conference/article/162624/">SC
Magazine. The talk will be given by David Byrne (the guy who
released grendel, not the guy
from Talking Heads), and Rohini Sulatycki. For my money, the most
important quote in the former article is, “There’s no patch
to fix these flaws, either. ‘All developers have to do is perform
a configuration change,’ he says, and encrypt view
state.”

I haven’t seen their presentation yet, but for Mojarra, you can
put lines 16 - 24 of the following web.xml into your web.xml to ensure
that client state will be encrypted.

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <web-app version="3.0" 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 http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
  3.     <servlet>
  4.         <servlet-name>Faces Servlet</servlet-name>
  5.         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
  6.         <load-on-startup>1</load-on-startup>
  7.     </servlet>
  8.     <servlet-mapping>
  9.         <servlet-name>Faces Servlet</servlet-name>
  10.         <url-pattern>/faces/*</url-pattern>
  11.     </servlet-mapping>
  12.     <welcome-file-list>
  13.         <welcome-file>faces/index.xhtml</welcome-file>
  14.     </welcome-file-list>
  15.  
  16.     <context-param>
  17.         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
  18.         <param-value>client</param-value>
  19.     </context-param>
  20.     <env-entry>
  21.         <env-entry-name>ClientStateSavingPassword</env-entry-name>
  22.         <env-entry-type>java.lang.String</env-entry-type>
  23.         <env-entry-value>driscoll</env-entry-value>
  24.     </env-entry>
  25. </web-app>
  26.  

A zipped netbeans project that does this is available at <http://mediacast.sun.com/users/edburns00/media/TestClientStatePassword.zip>

Related Topics >>
Blog Links >>

Comments

Config for Apache MyFaces

by mwessendorf - 2010-02-01 14:24

Hello Ed, similar to Mojarra you can avoid this on Apache MyFaces as well. There are some options documented here.

http://wiki.apache.org/myfaces/Secure_Your_Application

-Matthias

Yes, this is known problem,

by alexsmirnov - 2010-01-31 19:18

Yes, this is known problem, and that is why both JSF implementations have the view state encryption feature. Another hole has been introduced by JSF 2.0 AJAX feature there list of components to execute at form submission can be sent from client, so attacker has ability to change application logic ( bypass validation of some fields, for example ). There is no simple way to protect application from such vulnerability except additional checks in application code. That is why I've always been against "execute" or "update" parameters in AJAX request.