0

In JSF 2.2 new <f:viewAction> component was introduced and more importantly along with it a way to protect pages, that leverage this functionality, from CSRF attacks.

The feature is mentioned in the JSF 2.2 specification:

Call ViewHandler.getProtectedViewsUnmodifiable() to determine if the view for this viewId is protected. If not, assume the requested view is not protected and take no additional view protection steps. Obtain the value of the value of the request parameter whose name is given by the value of ResponseStateManager.NON_POSTBACK_VIEW_TOKEN_PARAM. If there is no value, throw ProtectedViewException. If the value is present, compare it to the return from ResponseStateManager.getCryptographicallyStrongTokenFromSession(). If the values do not match, throw ProtectedViewException. ...

What got me curious is how is the token used by getCryptographicallyStrongTokenFromSession() method generated in Mojarra, since that is the JSF implementation we use for some of our applications. I was quite surprised to find out that the implementation in versions prior 2.2.11 looks like this:

private String createCryptographicallyStrongToken() {
        // PENDING: http://java.net/jira/browse/JAVASERVERFACES-2204
        String result = "" + System.currentTimeMillis();

        return result;
    }

Since version 2.2.11 it seems to be implemented more robustly with the currentTimeMillis actually being encrypted using AES.

Since the non-encrypting versions of this implementation made their way into final releases of Wildfly 8.x server (8.0.0.Final, 8.1.0.Final, 8.2.0.Final and 8.2.1.Final) does this mean that applications deployed on these servers and relying on <protected-views> functionality are vulnerable?

JanM
  • 1,385
  • 1
  • 15
  • 25
  • Do you need to protect web pages on idempotent requests (which in turn is not required at all. Thus, it is not even a kind of protection)? The protection against CSRF is already implemented in JSF. The JSF framework itself does its job on its own. The concept of "*protected-views*" is really confusing. – Tiny Nov 07 '15 at 17:18
  • Related: http://stackoverflow.com/q/26969415 and https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL In my humble opinion, CSRF protection on idempotent requests is nonsense. Just use POST instead, or at most manage it yourself with a "shared key" or "authentication key" in a datastore separated from the webapp (e.g. SQL DB). – BalusC Nov 07 '15 at 22:54
  • Ok, makes sense if the requests really are idempotent. Could it be that this feature was then somehow intended for implementors who for some reason (probably wrong one) want to use and "protect" GET requests like /user/145/delete? Or what could be the reasoning behind introduction of this feature? – JanM Nov 08 '15 at 14:01

0 Answers0