Skip to main content

Hello Everyone, I believe I

4 replies [Last post]
Anonymous

Hello Everyone,

I believe I found a problem in the Glassfish interpretation of some combinations of security constraints in the deployment descriptor of web applications.

In particular, the problem seems to occur whenever one or more security constraints apply to the context root of a web application (/) and other constraints apply instead to every path under the context root (/*). One such example is given by the following configuration:

/*

/

According to Servlet spefication [1, 13.8.3] a HTTP request directed to the context root (such as "GET /") shall be denied in this case, since SC2 has the "best matching" URL pattern. In contrast, Glassfish allows any (even unauthenticated) requests to the context root. Notice that Tomcat behaves instead as prescribed by the Servlet specification and denies all the requests directed to the context root.

Does anyone know if there is any explanation to this behaviour?

[1] http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html

Matteo Casalino
Research Associate
Security & Trust
SAP Research, SAP Labs France SAS
805, avenue du Dr. Maurice Donat
06254 Mougins Cedex
T +334 92 28 - 63 42
E matteo.maria.casalino@sap.com
W http://www.sap.com/research

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kumar Jayanti Guest
Offline
Joined: 2011-04-02
Points: 0

On Aug 7, 2012, at 7:41 PM, CASALINO, Matteo Maria wrote:

> Hello Everyone,
>
> I believe I found a problem in the Glassfish interpretation of some combinations of security constraints in the deployment descriptor of web applications.
>
> In particular, the problem seems to occur whenever one or more security constraints apply to the context root of a web application (/) and other constraints apply instead to every path under the context root (/*). One such example is given by the following configuration:
>
>
>
>
>
> /*
>
>
>
>
>
>
>
> /
>
>
>
>
> According to Servlet spefication [1, 13.8.3] a HTTP request directed to the context root (such as "GET /") shall be denied in this case, since SC2 has the "best matching" URL pattern. In contrast, Glassfish allows any (even unauthenticated) requests to the context root. Notice that Tomcat behaves instead as prescribed by the Servlet specification and denies all the requests directed to the context root.
>
> Does anyone know if there is any explanation to this behaviour?

It seems like an interesting corner case that i never experimented before, but here are some relevant points from the JSR 115 Spec and Servlet Spec.

Kumar Jayanti Guest
Offline
Joined: 2011-04-02
Points: 0

On Aug 8, 2012, at 11:21 AM, KumarJayanti wrote:

>
>
> On Aug 7, 2012, at 7:41 PM, CASALINO, Matteo Maria wrote:
>
>> Hello Everyone,
>>
>> I believe I found a problem in the Glassfish interpretation of some combinations of security constraints in the deployment descriptor of web applications.
>>
>> In particular, the problem seems to occur whenever one or more security constraints apply to the context root of a web application (/) and other constraints apply instead to every path under the context root (/*). One such example is given by the following configuration:
>>
>>
>>
>>
>>
>> /*
>>
>>
>>
>>
>>
>>
>>
>> /
>>
>>
>>
>>
>> According to Servlet spefication [1, 13.8.3] a HTTP request directed to the context root (such as "GET /") shall be denied in this case, since SC2 has the "best matching" URL pattern. In contrast, Glassfish allows any (even unauthenticated) requests to the context root. Notice that Tomcat behaves instead as prescribed by the Servlet specification and denies all the requests directed to the context root.
>>
>> Does anyone know if there is any explanation to this behaviour?
>
> It seems like an interesting corner case that i never experimented before, but here are some relevant points from the JSR 115 Spec and Servlet Spec.
>

mgainty
Offline
Joined: 2004-05-21
Points: 0

http://download.oracle.com/otn-pub/jcp/jacc-1.0-fr-spec-oth-JSpec/jacc-1...

• If the pattern is a path prefix pattern, it must be qualified by
every path-prefix pattern in the deployment descriptor matched by (the pattern being qualified) *and*
different from the pattern being qualified.
The pattern must also be qualified by every exact pattern appearing in the deployment descriptor that is matched by the pattern being qualified.

• If the pattern is an extension pattern, it must be qualified by
every path-prefix pattern appearing in the deployment descriptor *and*
every exact pattern in the deployment descriptor that is matched by the pattern being qualified.

• If the pattern is the default pattern, "/", it must be qualified by
every other pattern except the default pattern appearing in the deployment descriptor.

• If the pattern is an exact pattern, its qualified form must not contain any qualifying
patterns.
icantly
it seems the spec lacks specific examples for each pattern use case the statistical probability of mis-interpretation for each pattern and mis-implementation is increased

Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.

Subject: Re:
From: v.b.kumar.jayanti...
Date: Wed, 8 Aug 2012 11:49:49 +0530
CC: ; ; paul.hendley...
To: users@glassfish.java.net

On Aug 8, 2012, at 11:21 AM, KumarJayanti wrote:

On Aug 7, 2012, at 7:41 PM, CASALINO, Matteo Maria wrote:Hello Everyone,

I believe I found a problem in the Glassfish interpretation of some combinations of security constraints in the deployment descriptor of web applications.

In particular, the problem seems to occur whenever one or more security constraints apply to the context root of a web application (/) and other constraints apply instead to every path under the context root (/*). One such example is given by the following configuration:

/*

/

According to Servlet spefication [1, 13.8.3] a HTTP request directed to the context root (such as "GET /") shall be denied in this case, since SC2 has the "best matching" URL pattern. In contrast, Glassfish allows any (even unauthenticated) requests to the context root. Notice that Tomcat behaves instead as prescribed by the Servlet specification and denies all the requests directed to the context root.

Does anyone know if there is any explanation to this behaviour?

It seems like an interesting corner case that i never experimented before, but here are some relevant points from the JSR 115 Spec and Servlet Spec.

865 Guest
Offline
Joined: 2011-06-24
Points: 0

On 8/8/12 9:38 AM, Martin Gainty wrote:
> http://download.oracle.com/otn-pub/jcp/jacc-1.0-fr-spec-oth-JSpec/jacc-1...
>
> • If the pattern is a*path prefix pattern*, it must be qualified by
> every path-prefix pattern in the deployment descriptor matched by (the
> pattern being qualified) *and*
> different from the pattern being qualified.
> The pattern must also be qualified/by every exact pattern /appearing
> in the deployment descriptor that is matched by the pattern being
> qualified.
>
> • If the pattern is an*extension pattern*, it must be qualified by
> every path-prefix pattern appearing in the deployment descriptor *and*
> every exact pattern in the deployment descriptor that is matched by
> the pattern being qualified.
>
> • If the pattern is the*default pattern*, "/", it must be qualified by
> every other pattern /except the default pattern appearing in the
> deployment descriptor./
>
> • If the pattern is an *exact pattern*, its qualified form must not
> contain any qualifying
> patterns.
> icantly
> it seems the spec lacks specific examples for each pattern use case
> the statistical probability of mis-interpretation for each pattern and
> mis-implementation is increased
Martin,

In a JACC compatible Servlet container such as Glassfish, when the
servlet path as derived from the request equals "/"
an empty-string servlet path is used in its stead in security-constraint
matching to ensure that the url-pattern "/"
is never an exact match for any request.

IOW, this was done to ensure that in this corner case, as in all other
cases, the default pattern "\' will have the lowest priority.

In the JACC spec this is spelled out in several places, most notable of
which may be:

4.1.1 Permission Names for Transport and Pre-Dispatch Decisions
The name of the permission checked in a transport or pre-dispatch
decision must
be the unqualified request URI minus the context path. All colon characters
occurring within the name must be represented using escaped encoding1.
For the
special case where this transformation of the request URI yields the
URLPattern
"/", the empty string URLPattern, "", must be used as the permission name.
For the special case where the empty string must be substituted for the "/"
pattern in the permission evaluation, all target related processing
(including
servlet mapping, filter mapping, and form based login processing) must be
performed using the original pattern, "/".

fwiw, there is similar language in the Servlet spec, although its
purpose may never have been revealed, and I personally
find it a bit difficult to understand.

As defined in the Servlet Spec Section 3.5 Request Path Elements

Servlet Path: The path section that directly corresponds to the
mapping which
activated this request. This path starts with a ’/’ character except
in the case
where the request is matched with the ‘/*’ or ““ pattern, in which
case it is an
empty string.

and of a similar nature 12.2 ...

"The empty string ("") is a special URL pattern that exactly maps to the
application's context root, i.e., requests of the form
http://host:port//. In this case the path info is ’/’ and the servlet path and
context path is
empty string (““)."

To your point about examples, I agree that it would be helpful if this
aspect of security-constraint
matching was made more visible in developer documentation.

For example, if you want to define a security constraint on the root of
your application, you would use the empty-string pattern to do so.

Ron

> Martin Gainty
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig.
> Diese Nachricht dient lediglich dem Austausch von Informationen und
> entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten
> Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den
> Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
>
>
>