Am 22.05.2014 15:51, schrieb Cor Bosman:
If it your opinion that the login page has to be CSFR protected then OK. BUT I don't want to have sessions started just for CSFR prevention for ANY code which is executed in not authenticated state
you refuse to understand how CSFR works
- at the first call the server generates a token
- the token is placed in a hidden filed
- before take any action the submitted token is verified
against the one from the first request
how do you genius imagine this works without storing the token in a session without start a session at all?
hint: you can't do without
Maybe the roundcube devs can explain which attack vector they are trying to prevent by having CSRF on the login page
i am not a roundcube dev but my job is development and security
- if you don't pass the token verification no login code is running
- the login in case of roundcube implies network connections
- the login in case of roundcube affects also the mailserver
the django project thought the same as you: https://www.djangoproject.com/weblog/2013/sep/15/security/
conclusion: whereever it is possible protect any expensive action with tokens, there are people out there thinking day and night how they can abuse things nobody imagines how they can be abused until it happened