Yesterday, MyFaces 1.2 was released. I took the opportunity to upgrade AppFuse Light and found it surprisingly easy to do so. The only issue I ran into is my testing logic no longer works. I haven't had a chance to dive deeper into trying to fix the problem, but I did check the code in.
Since I'm using Facelets with MyFaces, I figured it should be possible to run my app on Tomcat 5.x. No dice. I tried replacing MyFaces with Sun's RI (version 1.2_04) and voila! - it works.
From what I learned yesterday, it appears that MyFaces 1.2 will only run on a container that supports JSP 2.1. Sun's RI, on the other hand, will run on a Servlet 2.4/JSP 2.0 container. I don't know if Sun's RI is doing things properly, but it doesn't seem like Servlet 2.5 is required (which is kinda nice IMO).
You might ask why I care about JSP 2.0 vs. JSP 2.1? In reality, I don't. However, if I were to mix and match Struts 2 and JSF in the same application (using the Struts 2 JSF Plugin), I'd like to do it on a JSP 2.0 container. Why? Because OGNL (the EL in Struts 2) uses the pound sign (#) for expressions and JSP 2.1 hijacked that. Until the Struts team fixes that, I'm stuck on JSP 2.0. The workaround (disabling EL for all JSPs) doesn't seem like a good option to me.
In preparation for my talk at OSCON next week, I've been doing some research on cross-site scripting and how good Java web frameworks handle it. I'm disappointed to report that the handling of XSS in Java web frameworks is abysmal. First of all, the JSP EL doesn't bother to handle XSS:
With JSP 2.0 you can use the following to emit the description of a "todo" item:
${todo.description}
That's pretty nice. What happens when someone has entered a description like this?
<script type="text/javascript">alert('F#$@ you!');</script>
Well, it executes the JavaScript and pops up a nice little message to you.
...
My question is this: Why in the world did the expert group on the JSP 2.0 JSR decide to make not escaping XML content the default for EL expressions, when they made the opposite decision for c:out?
(Emphasis mine) If a company/developer wants to make sure their JSP-based code is not susceptible to XSS, they have two choices (as I see it):
- Do lots of code review to make sure <c:out> is used instead of ${}.
- Hack the jsp-compiler/el-engine to escape XML by default.
The good news is #2 doesn't seem to be that hard. I pulled down commons-el yesterday, added a hack to escape XML, re-jarred and put it in Tomcat 5.0.25's classpath. This actually worked and I was impressed it was so easy. However, when I looked at Tomcat 6, commons-el is no longer used and now there's a "jasper-el.jar" in the lib directory. I don't mind modifying another library, but what's the difference between jasper-el and commons-el?
Of course, the whole problem with JSP EL could be solved if Tomcat (and other containers) would allow a flag to turn on XML escaping by default. IMO, it's badly needed to make JSP-based webapps safe from XSS.
On a related note, there's a couple of web frameworks that I've found to be susceptible to XSS: namely Spring MVC and Struts 2. For Spring MVC, its <form:input> and <form:errors> tags are vulnerable. For Struts 2, OGNL expressions are evaluated, which is way worse than XSS and actually allows you to shutdown the JVM by putting %{@java.lang.System@exit(0)}" in a text field.
Even though it was surprising for me to see the issues with Struts 2 and Spring MVC, I'm somewhat glad they exist. If I hadn't discovered them, I might blissfully think that Java web frameworks aren't susceptible to XSS. However, it appears they're not only susceptible, but no one is really thinking about XSS when developing these framework. To further prove that theory, the Spring MVC and Struts 2 teams are aware of these issues, have been for quite some time - yet they've done nothing in the form of releasing upgrades or patches.
Seems kinda strange doesn't it?
