geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@savoirtech.com>
Subject Re: Potential Security Bug?
Date Fri, 29 Jul 2005 15:05:31 GMT

David Jencks wrote:
> I think our behavior is correct.  I don't quite understand what the 
> other possibilities are.  FWIW, I don't think we should   bend over 
> backward to support jsp pages not mentioned web.xml.

DJ, we have to support the behavior (to a degree - its in the JACC spec).

Per the JACC spec:

*******************
B.19 Calling isUserInRole from JSP not mapped to a Servlet

Checking a WebRoleRefPermission requires the name of a Servlet to 
identify the scope of the reference to role translation. The name of a 
scoping servlet has not been established for an unmapped JSP.
Resolution– For every security role in the web application add a 
WebRoleRefPermission to the corresponding role. The name of all such 
permissions shall be the empty string, and the actions of each 
permission shall be the corresponding role name. When checking a 
WebRoleRefPermission from a JSP not mapped to a servlet, use a 
permission with the empty string as its name and with the argument to 
isUserInRole as its actions. This specification will require that 
containers implement this resolution when the Servlet Specification
requires that containers test the caller for membership in the role 
named by the argument to isUserInRole when isUserInRole is called from 
an unmapped JSP.
*******************

In the JAASJettyRealm.isUserInRole() I see a call to 
JettyServletHolder.getCurrentServletName().  Does 
getCurrentServletName() return an empty String as required by the spec 
when its using an unmapped JSP?  I cannot find any code that 
specifically does this.  In Tomcat's version of 
TomcatGeronimoRealm.getServletName() I literally coded:

        /**
          * JACC v1.0 secion B.19
          */
         if (name.equals("jsp")) {
             name = "";
         }


Please let me know if I am not seeing something here or am not 
understanding this correctly.

Jeff


> 
> thanks
> david jencks
> 
> On Jul 28, 2005, at 7:52 PM, Jeff Genender wrote:
> 
>> Yes...there might be a bug here...
>>
>> IIRC, the Jetty JACC code did not test for JACC v1.0 section B.19 
>> which is an explicit test for JSPs under JACC.  I am not sure if this 
>> is the case here...but it sounds like it.
>>
>> I would like to see what David Jencks or Alan thinks about this.
>>
>> Jeff
>>
>> Gianny Damour wrote:
>>
>>> Hi,
>>> I have been trying to understand why I was not able to make the Java 
>>> Pet Store Supplier Application to pass a security check and I think 
>>> that I have discovered a potential bug. Prior to log it, I would like 
>>> to confirm that this is not a code issue in PetStore.
>>> The scenario is rather simple:
>>> * the url "/RcvrRequestProcessor" is secured and only the 
>>> "administator" role can access it;
>>> * a FORM based authentication is configured to log in the users;
>>> * the url "/RcvrRequestProcessor" plays the role of a dispatcher 
>>> servlet and forwards to the jsp file "/displayinventory.jsp";
>>> * within the jsp "/displayinventory.jsp" there is the following 
>>> security check " request.isUserInRole("administrator")"; and
>>> * this security check fails.
>>> I think that the security configuration is OK as I can log in and 
>>> successfully access the url "/RcvrRequestProcessor", which requires 
>>> an "administrator" role.
>>> However, isUserInRole fails. This is the Permission which is tested:
>>> (javax.security.jacc.WebRoleRefPermission jsp administrator)
>>> Against the following Permissions:
>>> java.security.Permissions@93139 (
>>> (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor 
>>> GET,POST)
>>> (javax.security.jacc.WebRoleRefPermission PopulateServlet administrator)
>>> (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor 
>>> administrator)
>>> )
>>> The "jsp" portion of the Permission being tested is the name of the 
>>> servlet being processed and comes from a JettyServletHolder 
>>> automatically registered for the processing of jsp files.
>>> If I add to the web.xml DD the following elements to explicitly 
>>> register the jsp "/displayinventory.jsp", then isUserInRole works as 
>>> expected:
>>>  <servlet>
>>>    <servlet-name>/displayinventory.jsp</servlet-name>
>>>    <jsp-file>/displayinventory.jsp</jsp-file>
>>>  </servlet>
>>>  <servlet-mapping>
>>>    <servlet-name>/displayinventory.jsp</servlet-name>
>>>    <url-pattern>/displayinventory.jsp</url-pattern>
>>>  </servlet-mapping>
>>> Indeed, with this explicit mapping, when isUserInRole is executed, 
>>> the Permission to be tested is:
>>> (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp 
>>> administrator)
>>> And the Permissions is:
>>> java.security.Permissions@18ef578 (
>>> (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp 
>>> administrator)
>>> (javax.security.jacc.WebRoleRefPermission PopulateServlet administrator)
>>> (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor 
>>> administrator)
>>> (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor 
>>> GET,POST)
>>> )
>>> As a matter of fact, I am not sure if this is a bug in our 
>>> implementation or in PetStore (FYI, I have found another 
>>> configuration issue for an ejb-jar.xml DD).
>>> Any idea?
>>> Thanks,
>>> Gianny
>>
>>

Mime
View raw message