On 09/02/2013 08:31 AM, Jan Pazdziora wrote:
I don't think we can use the recommended method where CSFR token is
stored in a requested page(ie in hidden element) because we don't
generate UI on a server.
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?
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.
Freeipa-devel mailing list