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.

Mac OS X search-styled JTextField

Posted on Dezember 12, 2010, under java, swing.

0

Working on some design stuff for university, I found out a very convenient way to get a Mac OS X search-style textfield (like you find in _every_ Mac application) out of a standard JTextField.

Running a Swing application on Mac OS X Java, you normally use the Mac look-and-feel com.apple.laf.AquaLookAndFeel out of the box. The UI classes of this look-and-feel support various client properties, which can be set via putClientProperty(Object key, Object value) on every JComponent. Now, to get a search-style for your JTextField you just have to set the following property:

jTextField.putClientProperty("JTextField.variant", "search");

And now your plain old JTextField looks like this:

Mac-style search field

In addition, there are a lot of other client properties, which can help you in building Mac OS X-style applications in Swing: http://developer.apple.com/library/mac/#technotes/tn2007/tn2196.html

Unfortunately this will only work when running the aforementioned Apple look-and-feel on a Mac OS X Java runtime environment (which will most likely be not available for > Java 6).

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

create annotation instances at runtime

Posted on September 26, 2010, under cdi, java.

3

Yesterday I stumbled upon an easy way to create annotation instances at runtime: javax.enterprise.util.AnnotationLiteral

This util class from CDI (JSR-299) implements all standard methods (toString(), equals(), hashCode(), annotationType()) just like an annotation instance created by Java would. Thus there is no real difference between subclasses from this class and the annotations created by the JRE.

Here you can find the source code of AnnotationLiteral from Apache Geronimo Specs: AnnotationLiteral.java

Example

For example you have the following annotation (which is also a CDI qualifier):

@Target({PARAMETER, FIELD, METHOD, CONSTRUCTOR, TYPE})
@Retention(RUNTIME)
@Documented

@Qualifier
public @interface ConversationQualifier1
{
    String value();
}

If you want to create an instance of it with a certain value at runtime, just create the following class:

public class MyConversationQualifier1
    extends AnnotationLiteral<ConversationQualifier1>
    implements ConversationQualifier1
{

    public String value()
    {
        return "my assigned value";
    }
}

Now you just need to create an instance of it and you can use it like any other annotation instance created by Java.

Annotation a = new MyConversationQualifier1();

« Older Entries