Not all crons run in CLI mode. You can't run in CLI mode if you want to give users the ability to use external cronjob services unless you use a script which is called by the external service by HTTP to start a shell script.
which completly defeats the idea of CSRF
So, you are saying that those who are not able to run crons by calling a shell script (shared hosting) should not be able to run Roundcube and its plugins?
i would not do that and looking at the price of a VPS where you can run real cronjobs i don't see a reason
As far as I understand CSFR it should prevent POST and AJAX-Requests from not authorized sources and nothing else
- a cronjob is a serverside action
- a serverside action must not be triggered uncrontrolled
Why do you have concerns to run HTTP based cronjobs?
because it's likely unsecure in many situations and you open a can of worms because it fights with server configurations and ressource limits because it fights with timeouts and what not
Well, this is off topic here. So, let's move this discussion to another topic.
I don't want to have sessions started when it is not needed. I'm not convinced by your argumentation. Why? Because at the end of time you are saying that plugin developers don't know what they have to do and they have to be protected against their own code.
that's why possible ressource intensive and long running things typically are not done within the webserver process
Isn't it true, that I have to know what is resource consuming when running code on Roundcube's startup hook? So, if your arguments are valid then you have to start a discussion about removal of 'startup' hook from Roundcube and to disallow code execution at all in not authenticated state. I'm curious what other plugin developers will say to such a consequence.
Of course there are IP or authorization token checks. I didn't say that Devs should disable security features.
but don't start a session because a random GET parameter leads in two options, none of them makes sense
- your request does anyways not work because the CSFR
- you disable also CSFR if the param is given which is not smart to
say it polite
See my comments above in regards to Roundcube's 'startup' hook.
Am 22.05.2014 14:55, schrieb Rosali:
Not all crons run in CLI mode. You can't run in CLI mode if you want to give users the ability to use external cronjob services unless you use a script which is called by the external service by HTTP to start a shell script.
which completly defeats the idea of CSRF
So, you are saying that those who are not able to run crons by calling a shell script (shared hosting) should not be able to run Roundcube and its plugins?
i would not do that and looking at the price of a VPS where you can run real cronjobs i don't see a reason
As far as I understand CSFR it should prevent POST and AJAX-Requests from not authorized sources and nothing else
- a cronjob is a serverside action
- a serverside action must not be triggered uncrontrolled
Why do you have concerns to run HTTP based cronjobs?
because it's likely unsecure in many situations and you open a can of worms because it fights with server configurations and ressource limits because it fights with timeouts and what not
Well, this is off topic here. So, let's move this discussion to another topic.
you came with cronjobs over http
I don't want to have sessions started when it is not needed
and it *is needed* for CSRF protection of the login form
I'm not convinced by your argumentation. Why? Because at the end of time you are saying that plugin developers don't know what they have to do and they have to be protected against their own code.
the server admin needs to be protected
that's why possible ressource intensive and long running things typically are not done within the webserver process
Isn't it true, that I have to know what is resource consuming when running code on Roundcube's startup hook? So, if your arguments are valid then you have to start a discussion about removal of 'startup' hook from Roundcube and to disallow code execution at all in not authenticated state. I'm curious what other plugin developers will say to such a consequence.
honestly *yes* there should not run any non-trivial code except session-management, CSRF protection and display the login form before successful authentication
not only for roundcube, for any web application
Of course there are IP or authorization token checks. I didn't say that Devs should disable security features.
but don't start a session because a random GET parameter leads in two options, none of them makes sense
- your request does anyways not work because the CSFR
- you disable also CSFR if the param is given which is not smart to
say it polite
See my comments above in regards to Roundcube's 'startup' hook
honestly i don't care about plugins and the web applications i am writing for more than 11 years now are all stripped down to not load any piece of un-needed code in whatever state as well as there are no maintainance operations over http without authentication, anything else is done in *real* cronjobs with a own user, his own php.ini and his own restrictions
after serious attacks (trying intrusion as well as DDOS) you know why and if it comes to security anybody who tries to setup here cronjobs called via the webserver no longer has access to do anything possible harmful
Not all crons run in CLI mode. You can't run in CLI mode if you want to give users the ability to use external cronjob services unless you use a script which is called by the external service by HTTP to start a shell script.
which completly defeats the idea of CSRF
So, you are saying that those who are not able to run crons by calling a shell script (shared hosting) should not be able to run Roundcube and its plugins?
i would not do that and looking at the price of a VPS where you can run real cronjobs i don't see a reason
As far as I understand CSFR it should prevent POST and AJAX-Requests from not authorized sources and nothing else
- a cronjob is a serverside action
- a serverside action must not be triggered uncrontrolled
Why do you have concerns to run HTTP based cronjobs?
because it's likely unsecure in many situations and you open a can of worms because it fights with server configurations and ressource limits because it fights with timeouts and what not
Well, this is off topic here. So, let's move this discussion to another topic.
you came with cronjobs over http
I don't want to have sessions started when it is not needed
and it *is needed* for CSRF protection of the login form
I'm not convinced by your argumentation. Why? Because at the end of time you are saying that plugin developers don't know what they have to do and they have to be protected against their own code.
the server admin needs to be protected
Well, I don't think an admin installs untrusted code.
As said, let's move this discussion to another topic. It is off topic here.
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. Roundcube developers did their job to provide secure code since they OFFER CSFR prevention. It is not their job to TOTALLY lock things for others who know what they are doing. Once again: As a consequence you have to ask to remove the 'startup' hook or (even more secure) to move plugins API initialization behind login (disallow any kind of third party code injection). I really hope that you never will be heard with such a request.
that's why possible ressource intensive and long running things typically are not done within the webserver process
Isn't it true, that I have to know what is resource consuming when running code on Roundcube's startup hook? So, if your arguments are valid then you have to start a discussion about removal of 'startup' hook from Roundcube and to disallow code execution at all in not authenticated state. I'm curious what other plugin developers will say to such a consequence.
honestly *yes* there should not run any non-trivial code except session-management, CSRF protection and display the login form before successful authentication
not only for roundcube, for any web application
Of course there are IP or authorization token checks. I didn't say that Devs should disable security features.
but don't start a session because a random GET parameter leads in two options, none of them makes sense
- your request does anyways not work because the CSFR
- you disable also CSFR if the param is given which is not smart to
say it polite
See my comments above in regards to Roundcube's 'startup' hook
honestly i don't care about plugins and the web applications i am writing for more than 11 years now are all stripped down to not load any piece of un-needed ... ... code in whatever state as well as there are no maintainance operations over http without authentication, anything else is done in *real* cronjobs with a own user, his own php.ini and his own restrictions
after serious attacks (trying intrusion as well as DDOS) you know why and if it comes to security anybody who tries to setup here cronjobs called via the webserver no longer has access to do anything possible harmful
Am 22.05.2014 15:28, schrieb Rosali:
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
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
The attack vector for CSRF through login page is not as useful as any attack vector once you are logged in. I mean, you are not logged in yet, so you can’t really generate any attacks that compromise your security.
There are perhaps some attacks possible if someone that also has an account on the same roundcube instance tricks you into logging into an account they control, but then you’ll be logged into their account. The possibilities for security related problems are limited, but there could be some privacy implications.
Maybe the roundcube devs can explain which attack vector they are trying to prevent by having CSRF on the login page.
Cor
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
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
The only attack vector I see is that you can be fooled into thinking you’re in your own account, while in fact you’re logged into someone else’s account. That still doesn’t compromise your account, but you could perhaps be fooled into giving away some privacy.
Anyways, im not advocating not having CSRF tokens on the login page, but it can be problematic to have sessions started in the login page in the use case I explained with many servers being health checked. I was able to work around it, so i personally dont see it is a huge problem to keep the sessions.
And I agree one should not use http into roundcube to run cron jobs :) Just check out some of the scripts in bin/ and use the clisetup.php to run tasks.
Cor
Am 22.05.2014 16:12, schrieb Cor Bosman:
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
The only attack vector I see is that you can be fooled into thinking you’re in your own account
*why don't you click on the link i posted* below the *content* of that link
and *after that* issue *many* smart people started to implement CSRF protection in the login process because it avoids completely to deal with the credentials
https://www.djangoproject.com/weblog/2013/sep/15/security/ ___________________________
Issue: denial-of-service via large passwords
Django's authentication framework -- django.contrib.auth -- includes a default User model and backend which authenticates via username and password. The raw password is not stored in the database; instead, a hashed version of the password is stored, and the hash is computed each time a user attempts to log in. The hasher to use is configurable, via the PASSWORD_HASHERS setting.
The default password hasher in Django is PBKDF2, which has the virtue of allowing the complexity of computing the hash to be effectively arbitrarily high, by repeated "rounds" of application before producing the final result. This increases the difficulty of attacks which use brute-force methods to compute the hashes of many possible plaintext values, in hopes of discovering which plaintext password corresponds to a given hashed value.
Unfortunately, this complexity can also be used as an attack vector. Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large -- and guaranteed-to-fail -- passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.
This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.
Although this is most effective against algorithms which are designed to be relatively "slow" to compute, such as PBKDF2 (which, again, is the default hasher in Django's authentication framework), it also is effective against other hashers, as the time to compute the hash generally grows with the size of the password.
To remedy this, Django's authentication framework will now automatically fail authentication for any password exceeding 4096 bytes.
On 05/22/2014 09:59 AM, Reindl Harald wrote:
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/
It's worth noting that django's mitigation of this issue *didn't* have to do with CSRF protection -- rather, they limited the size of the submitted passwords to 4KiB.
--dkg
Am 22.05.2014 16:42, schrieb Daniel Kahn Gillmor:
On 05/22/2014 09:59 AM, Reindl Harald wrote:
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/
It's worth noting that django's mitigation of this issue *didn't* have to do with CSRF protection -- rather, they limited the size of the submitted passwords to 4KiB
yes *for that* issue
but it's also worth noting that *if they would have* used CSRF protection for the login the issue never would have happened at least for bots not accepting a cookie and doing a second request with the correct token
if($token_class->verify($input_token)) { $user_class->login($username, $password); }
and the difference is that with limit the passwords to 4 KiB that single issue is solved, with the CSRF other issues in the future are also solved
- what if the hash-function is vulerable with special inputs
- what if someone just DOS your webmail
- what if your mailserver has rate-controls
- what if that rate-controls are not enabled for the webmail-host
you need to understand layered security and defensive programming to prevent fix this issue and that issue and the next issue because you did not imagine this and that and the next attack vector
besides limit the input data you proceed and security-tokens there are also two easy ways left with honeypot fields to make any webform more secure which leads to someone has to careful study the login page to achieve a single really processed login attempt wether the credentials are correct or not and *that* is how you have to design a sane application
I dont think anyone really wants to remove CSRF tokens from the login page. They have a use, no matter how small the risk. The protection is basically against people that dont have access to your login screen, but somehow manage to (make you) post to your login screen anyways. Thats enough reason to have sessions in the login screen, and Rosali should probably use a shell script to run those crontabs. Thats a much cleaner solution.
- what if your mailserver has rate-controls
Well, stop clicking that forged link then :)
Cor
I dont think anyone really wants to remove CSRF tokens from the login page. They have a use, no matter how small the risk. The protection is basically against people that dont have access to your login screen, but somehow manage to (make you) post to your login screen anyways. Thats enough reason to have sessions in the login screen, and Rosali should probably use a shell script to run those crontabs. Thats a much cleaner solution.
- what if your mailserver has rate-controls
Well, stop clicking that forged link then :)
Cor
Am 22.05.2014 15:34, schrieb Reindl Harald:
Am 22.05.2014 15:28, schrieb Rosali:
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?
I don't refuse how it works. I know how it works. Please read more carefully.
Roundcube has a plugin API and this API has a startu.
CURRENT CODE: Roundcube already executes code which is injected by the hook in question. There is currently no CSFR prevention if you don't use POST or AJAX requests. That's as it is and it is GOOD as is. I started a discussion not to start a session when there is no necessity. There is no necessity to start a session if already EXISTING code does not use the session in question. Currently the session is only used to approve POST and AJAX requests by request tokens. Nothing more and nothing less. So what? I hope this clarifies things for your genious imagine. Start a separate discussion if you are not happy with Roundcube AS IS. All what you are saying is off topic because it has nothing to do with the initial discusion to avoid unnecessary session starts.
hint: you can't do without
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
-
Cor Bosman -
Daniel Kahn Gillmor -
Reindl Harald -
Rosali