IdP CSRF Defence

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

IdP CSRF Defence

Philip Smart
Hi All,

I have put together three options for integrating a synchroniser token pattern based Cross Site Request Forgery (CSRF) defence into the IdP's Password authentication flow [1] (and potentially more widely). Each comes with an implementation (in a feature branch) on my personal git repository [2] (which should allow anonymous read access). 

Login CSRF is fairly difficult to exploit on the IdP in its current state, but an additional defence should make that more robust/concrete. 

This work does not represent production ready enhancements, or is not endorsed by anybody at this stage. It just represents some investigatory work and proof of concepts I have been working on. 

All comments welcome…including, why did you do that, why did you not just do this….



[1] <a href="https://wiki.shibboleth.net/confluence/display/DEV/CSRF&#43;Mitigation&#43;Options" class="">https://wiki.shibboleth.net/confluence/display/DEV/CSRF+Mitigation+Options
[2] [hidden email]:philsmart/java-identity-provider

Phil

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP CSRF Defence

Cantor, Scott E.
As much as I don't love the downside of having to do it all in "user space" so to speak, because of the ease of omitting it by accident, my experience with views, view scope, and on-XXXX rules in the flows is that they're fairly unreliable and subject to weird quirks. It's one thing to rely on them in ways that essentially break if something goes wrong, since that's safe, but relying on them to implement some kind of protective feature is less appealing to me.

I think to some degree we can automate the token checking by adding it to a new action base class that does the check in the preExecute hook, like the conditional action class does. Also easy to toggle on/off that way.

It's less SWF-dependent also that way of course, probably could be implemented to some degree at lower layers.

That's my take anyway. I'm sure there are trade-offs.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP CSRF Defence

Philip Smart
Hi Scott,

Thanks for the feedback.

On 8 Jul 2019, at 23:20, Cantor, Scott <[hidden email]> wrote:

As much as I don't love the downside of having to do it all in "user space" so to speak, because of the ease of omitting it by accident, my experience with views, view scope, and on-XXXX rules in the flows is that they're fairly unreliable and subject to weird quirks. It's one thing to rely on them in ways that essentially break if something goes wrong, since that's safe, but relying on them to implement some kind of protective feature is less appealing to me.

I guess providing whatever validation logic that is checking the token can not be bypassed (currently either an normal Profile Action or a SWF Listener), if something did go wrong and the token was not being set in the viewScope using an on-render tag etc. it would not be present in the view, and hence would fail validation when the form it is posted back.  

That said, I quite like the idea of having a token being set in the viewScope by a SWF Listener, over the reliance on configuring on-render rules.


I think to some degree we can automate the token checking by adding it to a new action base class that does the check in the preExecute hook, like the conditional action class does. Also easy to toggle on/off that way.

I did not think of that, so I will take a look this week. I can see a conditional profile configuration interface and base classes, but will need to check for a conditional action class.

Phil


It's less SWF-dependent also that way of course, probably could be implemented to some degree at lower layers.

That's my take anyway. I'm sure there are trade-offs.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]



Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IdP CSRF Defence

Cantor, Scott E.
> I guess providing whatever validation logic that is checking the token can not
> be bypassed (currently either an normal Profile Action or a SWF Listener), if
> something did go wrong and the token was not being set in the viewScope
> using an on-render tag etc. it would not be present in the view, and hence
> would fail validation when the form it is posted back.

Yes, though it's also true that "fails safe" is still "fails" and if there's no good way to get the on-render stuff working properly under some conditions, that just breaks the software.

What I observed was that on-render expressions at times failed to access the scopes reliably and variables that definitely were set would go missing. That wasn't a case of them not setting something in the view scope. but it led me to trust the whole engine less.

> That said, I quite like the idea of having a token being set in the viewScope by a
> SWF Listener, over the reliance on configuring on-render rules.

Other than the overhead and understanding exactly how it all works to know when to do what, it's certainly interesting. I need to look at the example.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP CSRF Defence

Philip Smart


> On 9 Jul 2019, at 17:31, Cantor, Scott <[hidden email]> wrote:
>
>> I guess providing whatever validation logic that is checking the token can not
>> be bypassed (currently either an normal Profile Action or a SWF Listener), if
>> something did go wrong and the token was not being set in the viewScope
>> using an on-render tag etc. it would not be present in the view, and hence
>> would fail validation when the form it is posted back.
>
> Yes, though it's also true that "fails safe" is still "fails" and if there's no good way to get the on-render stuff working properly under some conditions, that just breaks the software.

Ah right yes, I see now.

>
> What I observed was that on-render expressions at times failed to access the scopes reliably and variables that definitely were set would go missing. That wasn't a case of them not setting something in the view scope. but it led me to trust the whole engine less.
>
>> That said, I quite like the idea of having a token being set in the viewScope by a
>> SWF Listener, over the reliance on configuring on-render rules.
>
> Other than the overhead and understanding exactly how it all works to know when to do what, it's certainly interesting. I need to look at the example.

Yes, it is a limited PoC, but if you think (after looking) there is some merit in it, I will explore and test if further then write it up.

>
> -- Scott
>
> --
> To unsubscribe from this list send an email to [hidden email]
>

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.  

--
To unsubscribe from this list send an email to [hidden email]