[mitreid-connect] protecting authorize endpoint
Justin Richer
jricher at MIT.EDU
Fri Aug 21 12:59:04 EDT 2015
The original inquiry was whether or not the endpoint is protected — and it is. It’s included in the main UI filter, and therefore under the umbrella of Spring Security’s protection. I was asked to explain how that was happening, and that’s a job best suited for the documentation for the Spring Security project, not me. I tested this assertion and was unable to get past the authentication barrier.
However, I was mistaken in my assumption that it required ROLE_USER, as the code clearly only requires authentication of any kind. If you have a way to authenticate and get a session as an entity without ROLE_USER (which most implementations that I’m aware of won’t do because they’re not using other roles), then you could get an OAuth token issued for a whitelisted client without “real” user authentication. This is an interesting side case, but I can’t see how it would lead to a data breach in a properly configured system. The fix is simple, though, so it’s best to close it off since we found it.
However, claiming that I didn’t look into the issue and we could have fixed this if I had is really misleading. The authorization endpoint *is* protected (which was the original question, which was answered), but not in the exact way that we expected it to be, which has led to the discovery of this corner case. We wouldn’t have found it if Zhanna hadn’t gone digging through the code and documentation as she did, and for that I’m grateful. That’s what I meant by us not understanding the issue — the issue we found is not the one that was originally reported reported. It’s related, and we wouldn’t have found it without the original inquiry, and again for that I’m grateful; but it’s not a simple matter of a valid bug being ignored. There was no exploit given, no example, and no concern beyond not understanding how the system worked (for which the documentation and code is still a good answer).
— Justin
> On Aug 21, 2015, at 11:13 AM, Felipe Polo-Wood <felipe.polowood at duke.edu> wrote:
>
> Sorry Justin, I understand the concept of open source, but even in that case, if somebody needs to actually understand a security issue in order to report it, I think that puts a high bar for people to actually report security problems. Anybody that brings up a security issue should be taken seriously. I actually feel that Zhanna went above and beyond because of concern.
>
> Felipe Polo-Wood
> Sr. Manager
> Clinical Applications Technical Services
> Office: +1.919.668.2268
> Mobile: +1.919.741.4213
>
>
> From: mitreid-connect-bounces at mit.edu <mitreid-connect-bounces at mit.edu> on behalf of Justin Richer <jricher at mit.edu>
> Sent: Friday, August 21, 2015 11:02 AM
> To: Zhanna Tsitkov
> Cc: mitreid-connect at mit.edu
> Subject: Re: [mitreid-connect] protecting authorize endpoint
>
> 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 <mailto: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/390cf81f/attachment-0001.html
More information about the mitreid-connect
mailing list