Archive for 'jsf'

JSF value expression injection vulnerability

Posted on November 22, 2011, under jsf, security.

4

A few days ago this issue was reported to Mojarra: http://java.net/jira/browse/JAVASERVERFACES-2247.

It basically states that it is possible in JSF 2 to perform ValueExpression injection when includeViewParams is set to true on a navigation case.

To illustrate this in a better way, I created an example project at apache-extras, which shows the vulnerability: http://code.google.com/a/apache-extras.org/p/jsf-includeviewparams-security-hole-example/

Use the following steps to run the example:

  1. svn checkout http://svn.codespot.com/a/apache-extras.org/jsf-includeviewparams-security-hole-example/trunk/
  2. mvn clean jetty:run-exploded -PjettyConfig
  3. go to http://localhost:8080/include-view-params-security and follow the instructions

This vulnerability exists, because JSF treats the value of a view parameter as a ValueExpression when performing a navigation case with includeViewParams=true. For further details, see the issues at Mojarra and MyFaces: http://java.net/jira/browse/JAVASERVERFACES-2247 and https://issues.apache.org/jira/browse/MYFACES-3405

Until this is fixed you should avoid using includeViewParams=true!

Bachelor thesis about relative resource handler

Posted on November 8, 2011, under jsf, tu wien.

0

I am very happy to announce that I will write my bachelor thesis at the research group for industrial software (INSO) at Vienna University of Technology. The thesis will be about my work on the relative resource handler for JSF 2 [1].

Together with Marcus Büttner and Mark Struberg I will adapt the relative resource handler for the administration software of the Vienna University of Technology, TISS [2]. For this task the relative resource handler will include some new features apart from supporting relative paths between resources, like e.g. supporting external resource locations. Check out the issue tracker for all enhancements [3]. Also, we already created a wiki page [4] for a list of all requirements.

Stay tuned!

[1] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/
[2] https://tiss.tuwien.ac.at/
[3] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/issues/list
[4] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/wiki/Requirements

MyFaces 2.1 is now trunk

Posted on Mai 2, 2011, under jsf.

0

After a discussion about keeping our 2.0.x and 2.1.x branches in sync last week on the MyFaces dev mailing list, we decided to promote the 2.1.x branch to trunk. In addition, we created a 2.0.x maintenance branch.

MyFaces core 2.1.x is now here:

https://svn.apache.org/repos/asf/myfaces/core/trunk/
https://svn.apache.org/repos/asf/myfaces/shared/trunk/
or
https://svn.apache.org/repos/asf/myfaces/current21/

MyFaces core 2.0.x is now here:

https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.x/
https://svn.apache.org/repos/asf/myfaces/shared/trunk_4.0.x/
or
https://svn.apache.org/repos/asf/myfaces/current20/

JSF 2.2 Expert Group

Posted on April 29, 2011, under jcp, jsf, jsf 2.2.

0

I just joined the JSF 2.2 (JSR 344) Expert Group. However, my request is not 100% done, I need to sign and fax the JSPA first (will do so next week).

I joined the EG, because some issues which were chosen for JSF 2.2, were originated by myself, like JAVASERVERFACES_SPEC_PUBLIC-976 or JAVASERVERFACES_SPEC_PUBLIC-947 (see other blog post). In addition, I will certainly contribute code for some issues, e.g. for JAVASERVERFACES_SPEC_PUBLIC-947 (because this spec issue is the result of my AdvancedResourceHandler in MyFaces commons).

I am really looking forward to working with Ed Burns and the other EG members and to creating a kick-ass new version of JSF!

JSF 2.2 – spec issues with at least one vote

Posted on April 17, 2011, under jsf, jsf 2.2.

0

Here is a list of all open JSF spec issues with at least one vote: http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10514

Created via JIRA’s custom search query api.

JSF 2.2 – Vote for your top 5 issues

Posted on April 17, 2011, under jsf, jsf 2.2.

0

In the JSR-344 (= JSF 2.2) expert group kick-off meeting last wednesday in Vienna, Austria (which I was very glad to attend), the expert group agreed on letting everyone involved in JSF vote for their top 5 specification issues in the issue tracker. Ed Burns also announced this in this blog post.

There are currently about 330 open issues in the specification issues tracker and the number is slightly growing, since Ed told everyone to file their issues, because otherwise the problem “does not exist”.

Working through the open issues, I found out that there are some parts which do not have a spec issue yet, for example the question of integrating JSF’s managed bean mechanism with CDI (JSR-299) or the concept of CODI’s type-safe view config. Thus I created about 5 new issues in the tracker.

And here they are – my TOP 5 JSF 2.2 issues:

The first one comes from a discussion on the jsr-314-open list I had with Ed, Andy Schwartz and some other guys about (how I call it) “the epic fail targets attribute”. The second one is from Matthias Wessendorf and improves the Websocket support for JSF. The third one originates from my Advanced JSF 2 ResourceHandler implementation in MyFaces Commons. The fourth one comes from MyFaces CODI and the fifth one comes from Gerhard Petracek, a colleague of mine from IRIAN who is Bean Validation expert group member.

However, there are some other open issues, which I created, that I cannot vote for (simply because you cannot vote for the issues you created):

I you have some time, check them out and if you find them important enough, please vote! Deadline is Tuesday, April 19th, in the evening.

How to wrap a ValueExpression in EL 1.0 and 2.2

Posted on Dezember 15, 2010, under java, jsf, jsf 2.0.

2

The problem

A new Class was introduced in the EL API 2.2: javax.el.ValueReference. In addition javax.el.ValueExpression now provides the following method:

public ValueReference getValueReference(ELContext context)
{
    return null;
}

This makes wrapping of a javax.el.ValueExpression (which is actually a very common thing in projects like MyFaces or OpenWebBeans) not really an easy task if you have to support both EL versions in one project, because there are a lot of unanswered questions:

  • Which EL version should I use to compile the code?
  • Should the ValueExpression wrapper implement getValueReference()?
  • Do I need one wrapper or two?
  • How can I even determine the EL version at runtime?
  • …

To find a solution for this problem we have to take a closer look at the Java classloading mechanism:

What does the ClassLoader do?

After a lot of experimenting with different classpath configurations, I found out some pretty interesting things. For the experiments I used the following custom ValueExpression implementation:

import javax.el.ELContext;
import javax.el.ValueExpression;
import javax.el.ValueReference;

/**
 * @author Jakob Korherr
 */
public class MyValueExpression extends ValueExpression
{

    @Override
    public ValueReference getValueReference(ELContext context)
    {
        return new ValueReference("base", "property");
    }

    @Override
    public String toString()
    {
        return "toString() of MyValueExpression";
    }

    @Override
    public Object getValue(ELContext context)
    {
        return null;
    }

    @Override
    public void setValue(ELContext context, Object value)
    {
    }

    // ... other methods cut for clarity ...

}

Of course, you must compile this class using EL 2.2, because otherwise javax.el.ValueReference will not be present and you will get a compile error.

Now if you use this custom ValueExpression in any scenario in an EL 2.2 environment, everything will work just fine. However, the interesting part is using this class in an EL 1.0 environment, because here javax.el.ValueReference is NOT available.

At first I thought I will get a NoClassDefFoundError as soon as I use a MyValueExpression instance with EL 1.0. Thus I created the following test:

public static void main(String... args)
{
    ValueExpression m = new MyValueExpression();
    System.out.println(m);
}

However, it went well and I got “toString() of MyValueExpression” although my class references javax.el.ValueReference, which was not on the classpath.

Then I added private ValueReference valueReference; to MyValueExpression and ran the test again. To my surprise, it worked well again!

After a lot of tests, I found out just 2 scenarios which did not work with EL 1.0:

1) Calling a method on MyValueExpression which creates a new ValueReference or tries to call methods of it. OK, this can obviously not work with EL 1.0. You will get a java.lang.NoClassDefFoundError: javax/el/ValueReference

2) Calling m.getValueReference(). Here you will get the following error, because obviously this method is not available in EL 1.0: java.lang.NoSuchMethodError: javax.el.ValueExpression.getValueReference(Ljavax/el/ELContext;)Ljavax/el/ValueReference;

Solution

Because of the above findings you can just use EL 2.2 as compile dependency in your project and everything will work just fine also with EL 1.0, as long as you:

1) do not call ValueExpression.getValueReference()
2) do not call any method on ValueReference
3) do not create an instance of ValueReference

…outside of the getValueReference() method of your javax.el.ValueExpression implementation. Inside this method, you can do all of the above, because you will only get into this method if you’re using EL 2.2 at runtime!

Thus you can use this wrapper without any problems on EL 1.0:

import javax.el.ELContext;
import javax.el.ValueExpression;
import javax.el.ValueReference;

/**
 * @author Jakob Korherr
 */
public class ValueExpressionWrapper extends ValueExpression
{

    private ValueExpression wrapped;

    public ValueExpressionWrapper(ValueExpression wrapped)
    {
        this.wrapped = wrapped;
    }

    @Override
    public ValueReference getValueReference(ELContext context)
    {
        // You will only get here if EL 2.2 is available at runtime.
        // Thus you can use ValueReference without any problems!
        return wrapped.getValueReference(context);
    }

    @Override
    public Object getValue(ELContext context)
    {
        return wrapped.getValue(context);
    }

    @Override
    public void setValue(ELContext context, Object value)
    {
        wrapped.setValue(context, value);
    }

    // ... other methods cut for clarity ...

}

Using this wrapper in a pure EL 2.2 environment will not cause any problems when calling getValueReference() on the wrapper, because javax.el.ValueReference is provided by EL 2.2 at runtime.

Using this wrapper in a pure EL 1.0 environment will have the effect that getValueReference() is not visible at runtime and thus it will never get called and not cause any problems.

JSR-314 extended expert group

Posted on Oktober 31, 2010, under jsf.

0

Since this week I am allowed to post to the jsr-314-open mailing list and thus considered a member of the JSR-314 extended expert group. I am very happy with this, because I can finally raise my concerns with JSF 2.0 and 2.1 and also join some interesting discussions.

I already started a thread about the targets attribute of composite components. I kinda consider it an epic fail, and I already got consent of other EG members. Check it out: http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000604.html

MyFaces webapptest meets Apache SVN

Posted on September 9, 2010, under java, jsf, testing.

0

Since GSoC is over now, I integrated the “Automated webapp tests for MyFaces core and extensions”-project done by Cosmin Martinconi into the MyFaces codebase.

This test framework uses Arquillian to automatically configure and start a container (e.g. Tomcat or Jetty), to deploy the test cases on it and to execute them and run assertions using HtmlUnit and a JSF-PhaseListener. Currently this already works, however with a very limited set of features (and stability). You can check out a working example at https://svn.apache.org/repos/asf/myfaces/gsoc/webapptest/examples/simple

The project currently lives in the gsoc folder at https://svn.apache.org/repos/asf/myfaces/gsoc/webapptest and has its own component in the MyFaces test issue tracker (“webapptest“). In addition Cosmin created a wiki page showing the current state of the project (see http://wiki.apache.org/myfaces/AutomatedWebappTest_Status).

The MyFaces community already showed great interest on this project and I think we will be able to do a first alpha release of it in the near future. Afterwards MyFaces Webapptest will be used on MyFaces core and its subprojects to provide a fast and easy way of doing integration testing within a JUnit test case.

Custom ELResolver ordering in MyFaces

Posted on August 16, 2010, under jsf, jsf 2.0.

0

As with MyFaces core 2.0.2 (or 1.2.10) it is possible to change the predefined order or ELResolvers.

To change this predefined order you can provide a java.util.Comparator<ELResolver> implementation which will be applied to the List of ELResolvers mentioned above.

To install the comparator you simply have to set a web.xml config parameter:

<context-param>
    <param-name>
        org.apache.myfaces.EL_RESOLVER_COMPARATOR
    </param-name>
    <param-value>
        com.acme.el.MyELResolverComparator
    </param-value>
</context-param>

Apache OpenWebBeans optimization

To optimize the marriage of MyFaces and OpenWebBeans, you simply have to set the following config parameter:

<context-param>
    <param-name>
        org.apache.myfaces.EL_RESOLVER_COMPARATOR
    </param-name>
    <param-value>
        org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator
    </param-value>
</context-param>

This moves the WebBeansELResolver almost to the last place in the ELResolver chain, thus improving the overall performance of ELExpression evaluations.

Links

You can find more info in the MyFaces cwiki at https://cwiki.apache.org/confluence/display/MYFACES/ELResolver+ordering

« Older Entries