O365 auth bypass

[Ioannis Kakavas]

On April 27, 2016 8:28:01 PM GMT+03:00, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>On 4/27/16, 1:18 PM, "users on behalf of Rob Gorrell"
><users-bounces at shibboleth.net on behalf of rwgorrel at uncg.edu> wrote:
>
>
>
>>thought i would past this along for those that haven't seen... Looks
>like Microsoft had some significant problems with their SAML
>implementation in O365.
>>
>>http://www.economyofmechanism.com/office365-authbypass.html
>
>More precisely in their application.
Agreed. 
 There's nothing in SAML or any
>federated protocol that mitigates this, and even the Shibboleth-defined
>scope filtering idea only applies to some attributes.

It could be applied to the attribute they are using. 

 If you had a
>service using, say, employee number to link users in, you're going to
>be vulnerable without other checks.
>
>This is being misrepresented (and >dangerously so, IMHO) 

That's an overstatement IMHO.

>as a SAML issue
>because it gives people the idea that the middleware is enough to
>prevent this kind of problem. It's an

It's not claimed that the middleware would/should solve the issue. The write up is addressed to a general security aware audience, not to saml experts, and as though some things are simplified.
But you have to acknowledge the fact that if they used i.e. Shibboleth sp and the IDPEmail was scoped, they would be - by default - protected. 


Thanks for your comments! 

BR
Ioannis 

> application authorization bug and
>has to be approached from the application perspective to address
>properly without a lot of assumptions.
>
>One of the interesting things that cropped up in this though is that
>all this agonizing over their misuse of persistent ID appears to be
>even worse than it appeared: they apparently require it be present but
>don't *use* it...
>
>-- Scott

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.