geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Potential Security Bug?
Date Fri, 29 Jul 2005 15:53:46 GMT
now that  jeff has actually pointed out the relevant part of the spec I 
agree :-)

thanks
david jencks

On Jul 29, 2005, at 8:21 AM, Alan D. Cabrera wrote:

> Seems like a bug to me.  Let's file a Jira issue.
>
>
> Regards,
> Alan
>
> Jeff Genender wrote, On 7/29/2005 8:05 AM:
>
>>
>> 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