[RCD] Roundcube session management

Reindl Harald h.reindl at thelounge.net
Thu May 22 15:07:57 CEST 2014



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.roundcube.net/pipermail/dev/attachments/20140522/85727f66/attachment.sig>


More information about the dev mailing list