At long last, I’ve resurrected the JSF quick reference that I used to host at learnjsf.com. It’s on the JSF page above.
Archive for the ‘JavaServer Faces’ Category
JSF Quick Reference available again
Posted by David Chandler on October 23, 2009
Posted in JavaServer Faces | Leave a Comment »
Securing JSF Applications Against the OWASP Top Ten
Posted by David Chandler on October 6, 2009
My JSF security presentation in now available in PDF format from the Writings page above.
Posted in JavaServer Faces, Web App Security | 5 Comments »
JSF Welcome File Gotcha
Posted by David Chandler on March 6, 2009
When using web.xml’s welcome file capability to specify your application home page, make sure your editor (hint: Eclipse Web Tools?) doesn’t put in a leading slash.
Right:
<welcome-file-list>
<welcome-file>homePage.jsf</welcome-file>
</welcome-file-list>
Wrong:
<welcome-file-list>
<welcome-file>/homePage.jsf</welcome-file>
</welcome-file-list>
The leading slash in the second example will trip up JSF such that when you submit a form on the home page, it will simply reload the home page on the first click, and then do the action and navigate to a new page only on the second click. If you look closely in the URL, you’ll see a // in the path that causes the problem. Welcome files work in any directory (thus, no slash is needed), but Eclipse WTP appears to add a preceding slash when using the file chooser.
Note: if you’re using Tomcat and specify a welcome file with a jsf extension as shown, you’ll also need to create a dummy file with that extension in addition to the real JSP or .xhtml (facelets) view template to satisfy Tomcat’s welcome file existence check. I create a .jsf file with a single line:
<%// Dummy file to trick Tomcat into supporting welcome-file-list –%>
Posted in Headsmack, JavaServer Faces | Comments Off on JSF Welcome File Gotcha
MyFaces Requiredness Checking Resolved
Posted by David Chandler on December 19, 2006
After *much* discussion, MYFACES-1467 has been resolved (see previous post). The patch did not break the Sun TCK as originally thought, so it went in as UIInput.java version 478342 on 11/22/06.
/dmc
Posted in JavaServer Faces | Comments Off on MyFaces Requiredness Checking Resolved
Hacking JSF Requiredness Checking
Posted by David Chandler on October 14, 2006
MyFaces committer Matthias Weßendorf and I spent a few minutes this afternoon at ApacheCon confirming what I suspected about validation of required values in JSF. Normally, if you leave a required field empty, it will show up as an empty string and JSF will properly check for requiredness. But if, for a given required field, you remove the name-value pair from the POST altogether using a man-in-the-middle tool (MITM), JSF will not detect the missing required field. This is also an issue in the Sun RI and in fact results from unclear, if not conflicting, requirements in the JSF spec as detailed at the JIRA link below.
This issue is being tracked on the MyFaces JIRA https://issues.apache.org/jira/browse/MYFACES-1467, where you can also obtain the patch I’ve submitted.
/dmc
Posted in JavaServer Faces | Comments Off on Hacking JSF Requiredness Checking
MyFaces Security Presentation Now Available
Posted by David Chandler on October 11, 2006
My ApacheCon presentation, Securing MyFaces Applications Against the OWASP Top Ten, has been updated for OWASP 2007 and is available here as well as directly from my Writings page above (along with video).
Securing JSF Applications Against the OWASP Top Ten (PowerPoint)
/dmc
Posted in JavaServer Faces, Web App Security | 1 Comment »
Using Tomahawk Tree2 Component in a Portal
Posted by David Chandler on September 25, 2006
To run Tree2 with client-side expansion, you need JavaScript in the page <HEAD>. Normally, this gets added by the Tomahawk ExtensionsFilter. This doesn’t work in a portal, however, because servlet filters don’t run in a portal. There are some patches in MYFACES-434 (portlet filter) you may be able to use, but here’s an easier workaround. I’ve used this successfully with Tomahawk 1.1.3 in both Jetspeed2 and Liferay.
First, use Tree2 with server-side expansion so as not to require JavaScript. The ExtensionsFilter is therefore needed only to serve up the image resources needed by Tree2, and image requests are handled through the Faces Servlet, not the portal, so the ExtensionsFilter will run as normal for these requests. However, Tomahawk 1.1.3 checks to see if the ExtensionsFilter has been configured, which fails in the portal context. Fortunately, you can disable the check with a web.xml context param.
So to summarize, you can use Tree2 1.1.3 in a portal without any of the MYFACES-434 patches if
- You use server-side toggle
- You configure ExtensionsFilter as normal for the Faces Servlet
- You disable the ExtensionsFilter configuration check as follows in web.xml:
<context-param>
<param-name>org.apache.myfaces.CHECK_EXTENSIONS_FILTER</param-name>
<param-value>false</param-value>
</context-param>
/dmc
Posted in JavaServer Faces | Leave a Comment »
JSF Trick: Invoking an Action Method on an Item in a Datatable
Posted by David Chandler on September 8, 2006
Suppose you want to create a table of items and enable one or more action links for each item; for example, a list of files with a “check out” and “delete” link next to each. The usual approach is to create a java.faces.model.ListDataModel in your backing bean and call its getRowData() method from the action method in your backing bean to get the item for which the action was taken. These are great JSF features, but I recently found you can avoid even this code.
The trick is to put your action method in the class that represents the item. Then you can reference it directly in the view template, like this:
<h:dataTable value="#{fileMgr.items}" var="item">
<h:column>
<h:outputText value="#{item.name}" />
</h:column>
<h:column>
<h:commandLink value="Check out"
action="#{item.actionCheckOut}" />
</h:column>
</h:dataTable>
In this example, fileMgr is the backing bean, and item is the datatable var representing a model object. The trick here is that JSF will go ahead and call the actionCheckOut() method on the item object, even though it’s in a model class, not a backing bean. This way, you don’t even have to mess with ListDataModel.
Neat as this is, it is usually only appropriate in the case of simple toggle actions that affect only the item properties. Most other actions (especially delete) are likely to need references to the entire collection of items or other classes such as DAOs which you would not want to reference directly in a class representing a domain object such as an item. Still, it will save a layer of code for simple actions and I’m tickled that it works.
Posted in JavaServer Faces | Leave a Comment »
Securing MyFaces Applications Against the OWASP Top Ten
Posted by David Chandler on August 17, 2006
Update Oct 6, 2009: you can download this presentation from the Writings page above.
My presentation on this subject has been selected for the upcoming ApacheCon US 2006! If you’d like to be a technical reviewer beforehand, please e-mail me at the address on the Consulting menu above. See you there!
The JavaServer Faces (JSF) API is an excellent foundation for building secure Web applications because of its component-oriented nature, carefulness surrounding data validation, and numerous extension points. Apache myFaces builds on this strength by providing components which offer built-in protection against many of the OWASP Top Ten attacks including form parameter tampering and cross-site scripting. In this presentation, we’ll review how myFaces protects against these attacks and move on to explore JSF extensions you can deploy to provide complete protection against the OWASP Top Ten, including forced browsing, information leakage in select boxes, and unauthorized method execution. Specifically, we’ll look at centralized approaches to ensuring that every field and form is properly validated, a phase listener and view handler to prevent forced browsing and assist with detection of session hijacking, a customer converter and component to hide sensitive information such as IDs in menu options, and a JAAS permission checker for component actions (event handler methods).
/dmc
Posted in JavaServer Faces, Web App Security | Leave a Comment »
Disable Browser Caching in JSF
Posted by David Chandler on August 8, 2006
Browser caching of page content has negative security implications when your application runs on shared terminals (like the public library). You can turn it off with this simple phase listener. Well, maybe. As some of the comments indicate, browsers are finicky, and of course, we never trust the browser, anyway, so using this technique is certainly not a security guarantee of any kind.
package my.util;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import javax.servlet.http.HttpServletResponse;
public class CacheControlPhaseListener implements PhaseListener
{
public PhaseId getPhaseId()
{
return PhaseId.RENDER_RESPONSE;
}
public void afterPhase(PhaseEvent event)
{
}
public void beforePhase(PhaseEvent event)
{
FacesContext facesContext = event.getFacesContext();
HttpServletResponse response = (HttpServletResponse) facesContext
.getExternalContext().getResponse();
response.addHeader("Pragma", "no-cache");
response.addHeader("Cache-Control", "no-cache");
// Stronger according to blog comment below that references HTTP spec
response.addHeader("Cache-Control", "no-store");
response.addHeader("Cache-Control", "must-revalidate");
// some date in the past
response.addHeader("Expires", "Mon, 8 Aug 2006 10:00:00 GMT");
}
}
To register the phase listener, just add this to your faces-config.xml:
<lifecycle> <phase-listener id="nocache">my.util.CacheControlPhaseListener</phase-listener> </lifecycle>
Posted in JavaServer Faces, Web App Security | 65 Comments »
TurboManage 