On 09/03/2013 09:57 AM, Petr Vobornik wrote:
On 09/03/2013 02:50 AM, Jan Pazdziora wrote:
On Mon, Sep 02, 2013 at 05:57:16PM +0200, Petr Vobornik wrote:
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.
Does it have to be cookie?
What is the result of a login operation? It seems that at least for
the /ipa/session/login_password call, it is the result of
finalize_kerberos_acquisition which is return [''], and that empty
string is ignored by IPA.login_password's success_handler. Could the
return be the token, and get stored either to IPA.ui.csrf_token or
similar place, or stored to an element in the DOM? You don't really
need to use cookies for that.
It has one drawback. You won't have access to the token if you open new
instance of Web UI because you already have a session and therefore
don't need to log in.
I suppose we can create a new handler (can't be a command) which new Web
UI instance would call to obtain the token. Special care would be needed
to prevent cross origin usage though.
IMO the cookie is more secure, but I'm not a security expert ...
Maybe there is a way to avoid the cookie and the new handler.
DOM is not usable as a storage, but sessionStorage or localStorage [1]
might be.
Browser support: http://caniuse.com/namevalue-storage
[1] https://developer.mozilla.org/en-US/docs/Web/Guide/DOM/Storage
--
Petr Vobornik
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
