JSF_ViewState_InYourFace.pdf

(430 KB) Pobierz
JSF ViewState upside-down
JSF implementations are often used in J2EE applications. JSF uses
ViewStates which have already been discussed for cryptographic
weaknesses like with the oracle padding attack
[PADDING].
ViewStates
have also been abused to create client side attacks like Cross-Site
Scripting
[XSS].
But as shown in this research, they can also be used to
perform much more dangerous attacks on web applications.
Renaud Dubourguais - renaud.dubourguais@synacktiv.com
Nicolas Collignon - nicolas.collignon@synacktiv.com
www.synacktiv.com
14 rue Mademoiselle 75015 Paris
Table des matières
1.A few reminders.................................................................................................... 3
1.1.JSF implementations............................................................................................................... 3
1.2.The role of ViewState............................................................................................................. 3
1.3.Storage mode......................................................................................................................... 3
1.4.ViewState integrity and confidentiality...................................................................................5
2.Intrusion through the ViewState............................................................................6
2.1.Environment description........................................................................................................ 6
2.2.InYourFace tool description..................................................................................................... 7
2.3.Business data leak................................................................................................................. 7
2.4.Direct object references exploitation......................................................................................9
2.5.Bypassing user inputs validators.......................................................................................... 10
2.6.Arbitrary code execution...................................................................................................... 12
Conclusion............................................................................................................. 16
References ............................................................................................................ 17
2/17
1. A few reminders
The
JavaServer Faces
(JSF) concept has been introduced a few years ago and is today largely used within J2EE
applications. It adds an abstraction layer on one of the most tedious part in web applications development: the user interface.
The JSF layer helps integrating complex widgets within an application, such as:
•
•
•
graphic components with the use of dedicated tags;
automatic Ajax layer with the help of form attributes;
data export features in complex formats (ex: PDF, Excel, etc.).
However, it would be naive to think that adding this kind of features only facilitates developer's tasks. Indeed, it comes with
obscure and complex mechanisms. The ViewState is one of these mechanisms.
1.1. JSF implementations
The term “JSF” refers to a Java specification whose first version was published in 2004. Many implementations of this
specification exist. Among the most commonly used are
Mojarra
published by Sun (now Oracle) and
MyFaces
by the Apache
Foundation.
It is also common to observe applications using add-on libraries. They add an layer to this implementation and facilitate even
more the implementation of users interfaces complying with JSF specifications. Libraries such as
RichFaces, PrimeFaces,
Trinidad
and
Tomahawk
help to integrate complex graphical components with only a few lines of code but they can also add
new entry points for an attacker.
1.2. The role of ViewState
The goal of this paper is not to define precisely what is a ViewState. Microsoft already published an extensive documentation
[MSDN].
It describes the ASP.NET implementation but the concept also applies to JSF.
Developer's common vision of a ViewState is a large hidden HTML field (see. figure 1).
Fig.1: ViewState in action
From a more technical point of view, the ViewState is much more than bandwidth-intensive content. Its role is to memorize
the state of a web form as it will be viewed by the user, even after numerous HTTP queries (stateless protocol). The objective
is to store and restore results of users actions that impacted the user interface of a web page (choice within drop-down list,
check-box selection, etc).
1.3. Storage mode
All the implementations we have studied offer two ViewState storage methods: server side and client side. By default, most
implementations are configured to use server side storage. However the configuration can be modified using the following
parameter within the file
web.xml:
3/17
<context­param>
<param­name>javax.faces.STATE_SAVING_METHOD</param­name>
<param­value>[client|server]</param­value>
</context­param>
1.3.1. Server side storage
When the ViewState is stored by the server itself, it has to be identifiable among others and to remain specific to each user.
So it is stored in a user session and identified with a unique identifier sent to the user using a hidden field or within a
JavaScript code:
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="­
7249534836608350716:­2454600105753096458" autocomplete="off" />
When a user submits a form, the ViewState identifier is sent to the server. The server will be able to recover the associated
ViewState, rebuild the state of each widgets as viewed by the user and update them if needed. Notice that this kind of
storage is a major difference between JSF and ASP.NET. ASP.NET does not natively supports server side storage of a
ViewState.
1.3.2. Client side storage
When developers choose to store the ViewState on the client side, they are always inserted within an hidden field or
JavaScript code for all web pages containing HTML forms. The browser then send it to the remote server on each form
submission. The server is then in charge of restoring the state of graphic components.
In such configuration, the format of the ViewState is a serialized Java stream, compressed to
Gzip
format and encoded to
base 64 (see. figure 2). This format seems to be standardized for all JSF implementations. Some security layers can be
added as we will see later. This is the type of storage we will focus on.
Fig 2: ViewState encoding without a security layer.
1.3.3. Choice of the storage method
The choice of the storage method strongly depends on the web application's requirements. The main reason is often linked
to performances:
•
•
Client side storage would reduce server's memory load but increases network traffic volume and may increases the
CPU load when dealing with the ViewState decoding process.
Server side storage would relieve clients but becomes memory consuming if the managed graphical interface is
complex.
4/17
1.4. ViewState integrity and confidentiality
Several papers demonstrated that ViewState's client side storage offers, under certain conditions, new entry points to the
application and may be a vector of vulnerabilities if an attacker manipulates its content.
One of these papers pointed out that all
MyFaces
version 1.1.7, 1.2.8, 2.0 and earlier as well as
Mojarra
1.2.14, 2.0.2 and
earlier allowed graphical components injection within the application's pages if the ViewState was not protected
[XSS].
From
the exploitation point of view, it could allow arbitrary data injection in the user's session or Cross-Site Scripting attacks.
These papers were the first to point out the necessity to protect the ViewState if it's stored on the client side. Indeed, JSF
specifications earlier than 2.2 require the implementation of an encryption mechanism, but don't require its usage.
Fig. 3: ViewState encoding with security layer
The security layer can be enabled through specific configuration parameters. With
Mojarra,
the following lines (in the file
web.xml)
enable the ViewState data encryption. Notice that
Mojarra
does not perform an integrity check (HMAC):
<env­entry> 
<env­entry­name>com.sun.faces.ClientStateSavingPassword</env­entry­name> 
<env­entry­type>java.lang.String</env­entry­type> 
<env­entry­value>[YOUR_SECRET_KEY]</env­entry­value>
</env­entry>
With
MyFaces,
the following lines enable the ViewState encryption and the integrity check:
<context­param>
<param­name>org.apache.myfaces.USE_ENCRYPTION</param­name>
<param­value>true</param­value>
</context­param>
The encryption key as well as the algorithms may be specified. Otherwise they will be automatically generated by
MyFaces.
It should also be noted that JSF 2.2 specifications published in 2013 requires the ViewState encryption activation by default.
Before that,
Mojarra
implementation did not enable it by default unlike
MyFaces.
5/17

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin