O365 auth bypass

[Cantor, Scott]

On 4/27/16, 6:26 PM, "Ioannis Kakavas" <ikakavas at noc.grnet.gr> wrote:



>>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. 

I don't believe it was EPPN, was it?

There aren't many identifiers that are scoped. EPPN and eduPersonUniqueID are it. You can't just take any attribute that happens to end in a domain and treat it that way, because the whole community needs to recognize that semantic for things to work well.

The mail attribute for example is not scoped.

>>This is being misrepresented (and >dangerously so, IMHO) 
>
>That's an overstatement IMHO.

When you call the blog article "The road to hell is paved with SAML Assertions", I think that's a pretty misleading title. Anybody reading that is going to immediately assume that the issue was a flaw in either SAML itself or their SAML implementation, and neither of those is true.

It's a deployment flaw, not a software mistake. If anything, I'd replace SAML Assertions in that title with "Cloud" and you'd have a much more accurate title.

>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.

Well, obviously I think they're misrepresented, not simplified. I think a general audience would reach a very different conclusion from it.

>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.

If the attribute wasn't defined somewhere authoritatively to be scoped, I wouldn't have told anybody that asked to define it to the software that way, and so they wouldn't be.

-- Scott