SEC-2189: <sec:authorize url=""> could use wrong WebInvocationPrivilegeEvaluator

[spring-projects-issues]

q (Migrated from SEC-2189) said:

When using <sec:authorize url=""> it is possible situation when wrong WebInvocationPrivilegeEvaluator is used for access evaluation

It occurs when in security xml descriptor there're different contexts
and in the jsp in second context we use <sec:authorize url=""> to access url from second context.

for example:

in security.xml:

<http pattern="/qwe/" ...>
   ...
</http>
<http pattern="/admin/" ...>
   <intercept-url pattern="/admin/stats/**" access="hasRole('ROLE_ADMIN')"/>
   ...
</http>

in /admin/index.jsp:

<sec:authorize url="/admin/stats/index.jsp">        
   <a href="<spring:url value="/admin/stats/index.jsp"/>">link</a>
</sec:authorize>

on the /admin/index.jsp link will be displayed even if user doesn't have ROLE_ADMIN

It appears that the problem is in

org.springframework.security.taglibs.authz.AbstractAuthorizeTag#getPrivilegeEvaluator:

Map<String, WebInvocationPrivilegeEvaluator> wipes = ctx.getBeansOfType(WebInvocationPrivilegeEvaluator.class);
....
return (WebInvocationPrivilegeEvaluator) wipes.values().toArray()[0];

[spring-projects-issues]

Kazuki Shimizu said:

Hi Rob.

Are there the plan to resolve this issue ?
Today, this issue occurred in my application under development (using spring-security 3.2.4).

There is an good alternative method for resolve ?

[spring-projects-issues]

Kazuki Shimizu said:

Hi Rob.

I sent the pull-request.
Please review the modification.
#107

[spring-projects-issues]

Kazuki Shimizu said:

I re-sent pull-request.
#108

Wow, I can't believe this bug wasn't fixed yet
+1.
Better yet, +1000

[rwinch]

Unfortunately this isn't that straight forward.

The problem is that the WebInvocationPrivilegeEvaluator is chosen using the entire HttpServletRequest. The HttpServletRequest that is used to determine which WebInvocationPrivilegeEvaluator is NOT the current HttpServletRequest. Instead, we would need access to theHttpServletRequest` that is going to be used if the user clicked on that link.

This means in order to select the proper WebInvocationPrivilegeEvaluator we would need the user to provide all the details to create a mocked instance of HttpServletRequest which are not available. Additionally, this would become comber some quite quickly.

I've been considering some other approaches like using the Spring MVC methods to determine access. However, this has problems since method security can access variables which may be resolved using the "future" request as well.

In short, this is not an easy problem to solve. The way around it is to use the access attribute and check for the role that the user has (i.e. replicating the authorization in your URL mappings).

Well, you can make a fake request to the url, and see it it gets permitted. Otherwise, just disable the url functionality completely, since it's not working as advertised.

[rwinch]

Thanks for the suggestion.

This has the downside of actually performing the number of requests for the number of links you have on the page. I'm not sure this is a good approach.

What's more is how would the JSP tag library implement this? We do not know what JavaScript libraries are included in the page and do not want to mandate any particular JavaScript library (or even JavaScript at all) to use the lib.

If you really wanted to, you could pretty readily perform this logic with the JavaScript library of your choice. However, I'm not sure it is something I would do (because it is unlikely to scale well).

well, you can use resttemplate on server side..