On 09/02/2013 08:31 AM, Jan Pazdziora wrote:
On Thu, Aug 15, 2013 at 04:27:53PM +0200, Petr Viktorin wrote:


Alternatively, how essential is this requirement for the referer
header -- couldn't it be dropped, maybe via some config option?

Without it, a malicious link/button on any webpage (or e-mail) could
do any action in IPA, if clicked by a logged-in admin.

Could we change the CSRF protection method from the Referrer check to
some user session specific token?

I don't think we can use the recommended method[1] where CSFR token is stored in a requested page(ie in hidden element) because we don't generate UI on a server.

The only way to use the token, which I see, is to create CSFR token on login and returned it in a cookie. Web UI or other API consumer can read the token from the cookie. Then they will add this token as new method option. Server will compare the stored CSFR token with the value in the request. The cookie will be sent along with the request as well so it's value can be checked too but IMO it's not necessary. Attacker should not be able to read the cookie content because of different origin.

This can be applied only to session usage (/ipa/session/*). Kerberized API on ipa/xml and ipa/json will still require referer check.

[1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#General_Recommendation:_Synchronizer_Token_Pattern

--
Petr Vobornik

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to