[mitreid-connect] protecting authorize endpoint

Fri Aug 21 11:02:53 EDT 2015

If you had actually understood the issue enough to explain it thoroughly and didn’t expect other people to do the leg work for your investigation, then I agree that we could have found this much sooner.

Nobody forced you to bring it to a public list.

Thank you for your contribution,

 — Justin

> On Aug 21, 2015, at 10:44 AM, Zhanna Tsitkov <tsitkova at mit.edu> wrote:
> 
> I am glad that we are finally on the same page with this issue.  It could have happened a couple of emails before if you would inspect the issue instead of sending me to reading Spring documentation.  It that case I would not be forced to bring it to the public list first.
> Thanks,
> Zhanna
> 
> On Aug 21, 2015, at 10:21 AM, Justin Richer <jricher at MIT.EDU <mailto:jricher at MIT.EDU>> wrote:
> 
>> I’ve been digging into this for the past half hour with all kinds of different combinations. On further investigation, it does look like the system can be coerced to give a token to a valid user without ROLE_USER. The authorization endpoint is protected, and tokens still cannot be generated without a valid login. The default implementation of MITREid Connect only uses ROLE_USER and ROLE_ADMIN for user accounts, so this is a bit of a moot point for both the default and the general case. This could be problematic for the new UMA server which uses ROLE_EXTERNAL_USER, but there’s still no chance of accessing local identity data or impersonating another user. Non-whitelisted sites are still bounced through the approval page, which does require ROLE_USER and mitigates this issue.
>> 
>> So to summarize, if your system has user accounts with a role other than ROLE_USER (most don’t) and if you have whitelisted sites, then it’s possible to get a token for the non-ROLE_USER account on a whitelisted site. To tighten security and prevent unexpected behavior, we’ve patched the configuration to account for this, filed (and patched) in this issue:
>> 
>>   https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/892 <https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/892>
>> 
>> The fix is simple, just add this line to the main <security:http> block in user-context.xml or equivalent:
>> 
>> <security:intercept-url pattern="/authorize" access="hasRole('ROLE_USER')" />
>> 
>> 
>> Thank you for looking into this matter, though in the future if you really believe it to be a security issue that would affect in-production systems, it’s considered bad form to disclose your findings on a public list first.
>> 
>>  — Justin
>> 
>> 
>>> On Aug 21, 2015, at 9:43 AM, Justin Richer <jricher at mit.edu <mailto:jricher at mit.edu>> wrote:
>>> 
>>> I am unable to replicate the exploit. Even when the client has been whitelisted, when going to the authorization endpoint, I am prompted to log in. I am unable to generate a token from an unauthenticated user, and so I don’t believe this is a security issue.
>>> 
>>>  — Justin
>>> 
>>>> On Aug 21, 2015, at 9:30 AM, Zhanna Tsitkov <tsitkova at mit.edu <mailto:tsitkova at mit.edu>> wrote:
>>>> 
>>>> Justin,
>>>> While debugging workflow related to authorization code request I found that authorization  EP provided by Spring Security OAuth2 (org.springframework.security.oauth2.provider.endpoint.AuthorizationEndpoint)  namespace is not protected as it’s supposed. I was able to enter this EP without any authentication.  Section "Configuring the Endpoint URL“ of “OAuth 2 Developer Guide” states  (See https://github.com/spring-projects/spring-security-oauth/blob/master/docs/oauth2.md <https://github.com/spring-projects/spring-security-oauth/blob/master/docs/oauth2.md>): “N.B.  The Authorization endpoint /oauth/authorize (or its mapped alternative) should be protected using Spring Security so that it is only accessible to authenticated users.“.  The example provided in the document implies that the endpoint must be protected from outside by the Spring Security framework.
>>>> There is some sort of protection within the endpoint itself, but it certainly does not require ROLE_USER  authority as you suggested previously. I was able to pass internal security check using different role. 
>>>> On the other hand, the other OAuth2 endpoint responsible for user approval process  "/oauth/confirm_access” is protected as  expected. 
>>>> Thus, this endpoint mitigate the lack of proper security for authorize endpoint. But, it seems to me that for white-listed clients  it does not matter. 
>>>> 
>>>> In my opinion it is a security issue of MitreID Connect.
>>>> 
>>>> Thanks,
>>>> Zhanna
>>>> 
>>>> On Aug 20, 2015, at 4:48 PM, Justin Richer <jricher at MIT.EDU <mailto:jricher at MIT.EDU>> wrote:
>>>> 
>>>>> I suggest reading the documentation for Spring Security and Spring Security OAuth.
>>>>> 
>>>>>  — Justin
>>>>> 
>>>>>> On Aug 20, 2015, at 10:21 AM, Zhanna Tsitkov <tsitkova at mit.edu <mailto:tsitkova at mit.edu>> wrote:
>>>>>> 
>>>>>> ok. Sounds good. Can you please point to a particular place where this is implemented. 
>>>>>> 
>>>>>> Thanks,
>>>>>> Zhanna
>>>>>> 
>>>>>> On Aug 20, 2015, at 10:14 AM, Justin Richer <jricher at mit.edu <mailto:jricher at mit.edu>> wrote:
>>>>>> 
>>>>>>> The rest of Spring Security, which is configured throughout the code, outside the XML. Specifically, the authorization endpoint requires ROLE_USER to access.
>>>>>>> 
>>>>>>>  — Justin
>>>>>>> 
>>>>>>>> On Aug 20, 2015, at 10:04 AM, Zhanna Tsitkov <tsitkova at mit.edu <mailto:tsitkova at mit.edu>> wrote:
>>>>>>>> 
>>>>>>>> In this block access intercept is set to permitAll: <security:intercept-url
>>>>>>>> pattern="/**"
>>>>>>>> access="permitAll"
>>>>>>>>  />
>>>>>>>> What mechanism is used to protect this EP?  
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Zhanna
>>>>>>>> 
>>>>>>>> On Aug 20, 2015, at 9:47 AM, Justin Richer <jricher at MIT.EDU <mailto:jricher at MIT.EDU>> wrote:
>>>>>>>> 
>>>>>>>>> As it says in the paragraph of documentation that you quoted below, it’s protected the same way that the rest of the UI is protected. This is handled in the main <security:http> block in user-context.xml. 
>>>>>>>>> 
>>>>>>>>>  — Justin
>>>>>>>>> 
>>>>>>>>>> On Aug 20, 2015, at 9:45 AM, Zhanna Tsitkov <tsitkova at mit.edu <mailto:tsitkova at mit.edu>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> According to the documentation for configure method of
>>>>>>>>>>  AuthorizationServerConfigurer
>>>>>>>>>> interface
>>>>>>>>>> "
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> * The /oauth/authorize endpoint also needs to be secure, but that is a normal user-facing endpoint and should be
>>>>>>>>>> 
>>>>>>>>>> * secured the same way as the rest of your UI, so is not covered here. The default settings cover the most common
>>>>>>>>>> 
>>>>>>>>>> * requirements, following recommendations from the OAuth2 spec, so you don't need to do anything here to get a
>>>>>>>>>> 
>>>>>>>>>> * basic server up and running.
>>>>>>>>>> "
>>>>>>>>>> In MitreID Connect it looks like  this EP is not explicitly protected.   How it is done? 
>>>>>>>>>> Thanks,
>>>>>>>>>> Zhanna
>>>>>>>>>> _______________________________________________
>>>>>>>>>> mitreid-connect mailing list
>>>>>>>>>> mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>
>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/mitreid-connect <http://mailman.mit.edu/mailman/listinfo/mitreid-connect>
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> mitreid-connect mailing list
>>> mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>
>>> http://mailman.mit.edu/mailman/listinfo/mitreid-connect <http://mailman.mit.edu/mailman/listinfo/mitreid-connect>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150821/1b3bddc0/attachment-0001.html