Hello,
I noticed that the contacts get exposed on the compose page, that is, everyone reading the source could take the whole list in a text file, so he could send spam.
It's not a problem for personal contacts, but if you're in a huge company using LDAP, this could not be a good idea.
One of our programmers get around this, but using ajax and getting the contacts straight to a certain javascript var, instead of defining that on the page code. Since Roundcube has new realeases we had to do the workaround every time.
Maybe you can integrate this "feature" on the mainstream, if of your interest. I can send the hacked code for the version 0.1.
Thanks a lot
Jonathan Araújo
Administrador de Infra-estrutura de TI
Gerência de TI - INDG S.A.
Este documento pode incluir informação confidencial e de propriedade restrita do Instituto de Desenvolvimento Gerencial-INDG e apenas pode ser lido por aquele(s) a quem sido endereçado. Se você recebeu esta mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer opiniões ou informações contidas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com as do Instituto de Desenvolvimento Gerencial-INDG. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito do Instituto de Desenvolvimento Gerencial-INDG.
List info: http://lists.roundcube.net/dev/
Hi!
Jonathan Batista de Araujo Neto wrote:
Hello,
I noticed that the contacts get exposed on the compose page, that is, everyone reading the source could take the whole list in a text file, so he could send spam.
It does not really make any difference if the code is there as raw HTML or as JavaScript array - it is still data that is transferred from the server to the client so it can be read and used in other ways than you would expect.
It’s not a problem for personal contacts, but if you’re in a huge company using LDAP, this could not be a good idea.
One of our programmers get around this, but using ajax and getting the contacts straight to a certain javascript var, instead of defining that on the page code. Since Roundcube has new realeases we had to do the workaround every time.
Still the data is transferred over the wire... no difference.
Maybe you can integrate this “feature” on the mainstream, if of your interest. I can send the hacked code for the version 0.1.
Thanks a lot
Jonathan Araújo
Administrador de Infra-estrutura de TI
Gerência de TI - INDG S.A.
List info: http://lists.roundcube.net/dev/
Hello,
I understand that it won't improve security level ( security by obscurity issue), but at last we would not like dummy users ( 95% of them) easily getting the whole list of contacts. A smarter user could get the contacts, nevertheless.
Maybe it would be interesting to have only some contacts, say that ones that appear at the drop list, be fetched with ajax while typing. If the user changes the "to:", then ajax would "renew" these contacts. Again, a smart user still could create a script to automate the process of getting the contacts, but it would be hard.
I guess it would also improve the speed of the compose page, in case we have thousands of contacts, like me.
Jonathan Araújo Administrador de Infra-estrutura de TI Gerência de TI - INDG S.A.
-----Mensagem original----- De: dev-bounces+jonathanneto=indg.com.br@lists.roundcube.net [mailto:dev-bounces+jonathanneto=indg.com.br@lists.roundcube.net] Em nome de Michael Baierl Enviada em: terça-feira, 28 de outubro de 2008 10:52 Para: RoundCube Dev Assunto: Re: [RCD] Contacts gettiong exposed on html
Hi!
Jonathan Batista de Araujo Neto wrote:
Hello,
I noticed that the contacts get exposed on the compose page, that is, everyone reading the source could take the whole list in a text file, so he could send spam.
It does not really make any difference if the code is there as raw HTML or as JavaScript array - it is still data that is transferred from the server to the client so it can be read and used in other ways than you would expect.
It's not a problem for personal contacts, but if you're in a huge company using LDAP, this could not be a good idea.
One of our programmers get around this, but using ajax and getting the contacts straight to a certain javascript var, instead of defining that on the page code. Since Roundcube has new realeases we had to do the workaround every time.
Still the data is transferred over the wire... no difference.
Maybe you can integrate this "feature" on the mainstream, if of your interest. I can send the hacked code for the version 0.1.
Thanks a lot
Jonathan Araújo
Administrador de Infra-estrutura de TI
Gerência de TI - INDG S.A.
List info: http://lists.roundcube.net/dev/
Este documento pode incluir informação confidencial e de propriedade restrita do Instituto de Desenvolvimento Gerencial-INDG e apenas pode ser lido por aquele(s) a quem sido endereçado. Se você recebeu esta mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer opiniões ou informações contidas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com as do Instituto de Desenvolvimento Gerencial-INDG. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito do Instituto de Desenvolvimento Gerencial-INDG.
List info: http://lists.roundcube.net/dev/
I On Tue, Oct 28, 2008 at 4:30 PM, Jonathan Batista de Araujo Neto jonathanneto@indg.com.br wrote:
Hello,
I understand that it won't improve security level ( security by obscurity issue), but at last we would not like dummy users ( 95% of them) easily getting the whole list of contacts. A smarter user could get the contacts, nevertheless.
I don't understand, is your entire addressbook "exposed", or just the user's contacts?
Also, if a user has access to your addressbook, isn't there a certain level of trust already?
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
I don't understand, is your entire addressbook "exposed", or just the user's contacts?
The common LDAP addressbook is "exposed" at the compose page code. There's no problem of one user reading the contacts of someone else.
Also, if a user has access to your addressbook, isn't there a certain level of trust already?
Yes, there's some level trust. All my users can send emails to each other, placing the desired contacts in the "to:", "bcc:" or "cc:" fields.
What I'm wanting to avoid is that someone just "right click" on the compose page and "show source code". Then, copy all contacts, and past it at "bcc:", for sending spam for all other users.
He would have to hack the HTML page and open another .js file or create a script for getting it with an ajax page. That is, I want get things harder for dummy users wishing to send spam mail.
Thanks a lot for your help
Jonathan Araújo Administrador de Infra-estrutura de TI Gerência de TI - INDG S.A.
Este documento pode incluir informação confidencial e de propriedade restrita do Instituto de Desenvolvimento Gerencial-INDG e apenas pode ser lido por aquele(s) a quem sido endereçado. Se você recebeu esta mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer opiniões ou informações contidas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com as do Instituto de Desenvolvimento Gerencial-INDG. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito do Instituto de Desenvolvimento Gerencial-INDG.
List info: http://lists.roundcube.net/dev/
Ok, now I verified the issue - all contacts are shown in a JavaScript section of the page when a new mail is composed - this is not very smart for two reasons. One has already been outlined - security - but the other one is even more important - performance.
Imagine there are 500 contacts in the database - all of those will be transferred whenever a mail is composed, which is not needed. Instead the auto-completion should use an AJAX request back to the server and don't search on the client side. Yeah, it will be a bit slower for the end user to get suggestions on autocompletion, but the overall page will load way faster!
Any plans to fix this in the next Roundcube release?
Mike
Jonathan Batista de Araujo Neto wrote:
I don't understand, is your entire addressbook "exposed", or just the user's contacts?
The common LDAP addressbook is "exposed" at the compose page code. There's no problem of one user reading the contacts of someone else.
Also, if a user has access to your addressbook, isn't there a certain level of trust already?
Yes, there's some level trust. All my users can send emails to each other, placing the desired contacts in the "to:", "bcc:" or "cc:" fields.
What I'm wanting to avoid is that someone just "right click" on the compose page and "show source code". Then, copy all contacts, and past it at "bcc:", for sending spam for all other users.
He would have to hack the HTML page and open another .js file or create a script for getting it with an ajax page. That is, I want get things harder for dummy users wishing to send spam mail.
Thanks a lot for your help
On Tue, Oct 28, 2008 at 3:57 PM, Michael Baierl mail@mbaierl.com wrote:
Ok, now I verified the issue - all contacts are shown in a JavaScript section of the page when a new mail is composed - this is not very smart for two reasons. One has already been outlined - security - but the other one is even more important - performance.
Again, YOUR contacts show in the html source and you talk about security? Or am I mis-understanding an issue here.
Imagine there are 500 contacts in the database - all of those will be transferred whenever a mail is composed, which is not needed. Instead the auto-completion should use an AJAX request back to the server and don't search on the client side. Yeah, it will be a bit slower for the end user to get suggestions on autocompletion, but the overall page will load way faster!
No, it's easier and less expensive to pull it once and so to speak "cache" them in the source code/clientside and perform the auto-complete without a server request. Otherwise it will be slower and more expensive as you hit the database or your LDAP directory for every key-event.
Any plans to fix this in the next Roundcube release?
As far as I can see, there is no bug here and nothing to be fixed.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
One who cares so much about security should not use an address book, nor web-mail.
There's really no security concern here.
Regards, D.
till ??????:
On Tue, Oct 28, 2008 at 3:57 PM, Michael Baierl mail@mbaierl.com wrote:
Ok, now I verified the issue - all contacts are shown in a JavaScript section of the page when a new mail is composed - this is not very smart for two reasons. One has already been outlined - security - but the other one is even more important - performance.
Again, YOUR contacts show in the html source and you talk about security? Or am I mis-understanding an issue here.
Imagine there are 500 contacts in the database - all of those will be transferred whenever a mail is composed, which is not needed. Instead the auto-completion should use an AJAX request back to the server and don't search on the client side. Yeah, it will be a bit slower for the end user to get suggestions on autocompletion, but the overall page will load way faster!
No, it's easier and less expensive to pull it once and so to speak "cache" them in the source code/clientside and perform the auto-complete without a server request. Otherwise it will be slower and more expensive as you hit the database or your LDAP directory for every key-event.
Any plans to fix this in the next Roundcube release?
As far as I can see, there is no bug here and nothing to be fixed.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
till wrote:
Again, YOUR contacts show in the html source and you talk about security? Or am I mis-understanding an issue here.
I did not bring up the security issue nor did I test what happens in case of an LDAP directory.
No, it's easier and less expensive to pull it once and so to speak "cache" them in the source code/clientside and perform the auto-complete without a server request. Otherwise it will be slower and more expensive as you hit the database or your LDAP directory for every key-event.
So every time I compose a new mail all my 500 (imagine 1000 or 5000 contacts!) are downloaded to the client... instead of just my girlfriends contact via AJAX whom I want to send a mail to. Not very efficient on slow connections!
Mike
till wrote:
On Tue, Oct 28, 2008 at 3:57 PM, Michael Baierl mail@mbaierl.com wrote:
No, it's easier and less expensive to pull it once and so to speak "cache" them in the source code/clientside and perform the auto-complete without a server request. Otherwise it will be slower and more expensive as you hit the database or your LDAP directory for every key-event.
I agree that populating the contacts upfront can be faster and less expensive for many or maybe most installations. However, it isn't really an option for very large LDAP directories. Some directories simply will not return a full listing of all users.
In our environment, we have modified the autocomplete to do an ajax request because we wanted to provide our users with a list of their personal contacts combined with contacts pulled from a very large ldap system. We have plenty of extra LDAP server muscle, so repeated queries aren't a concern (and we're doing caching in php as a part of our patch).
Cheers, Ziba _______________________________________________ List info: http://lists.roundcube.net/dev/
On Tue, Oct 28, 2008 at 5:18 PM, Ziba Scott ziba@umich.edu wrote:
till wrote:
On Tue, Oct 28, 2008 at 3:57 PM, Michael Baierl mail@mbaierl.com wrote:
No, it's easier and less expensive to pull it once and so to speak "cache" them in the source code/clientside and perform the auto-complete without a server request. Otherwise it will be slower and more expensive as you hit the database or your LDAP directory for every key-event.
I agree that populating the contacts upfront can be faster and less expensive for many or maybe most installations. However, it isn't really an option for very large LDAP directories. Some directories simply will not return a full listing of all users.
Point well taken. :-)
In our environment, we have modified the autocomplete to do an ajax request because we wanted to provide our users with a list of their personal contacts combined with contacts pulled from a very large ldap system. We have plenty of extra LDAP server muscle, so repeated queries aren't a concern (and we're doing caching in php as a part of our patch).
Do you want to provide your patch?
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
We have about 1500 contacts and we didn't have any problems with performance at all. Maybe because all our clients have good Internet connection. I don't see this as a bug or issue, sorry if it sounded like this.
According to our company's police, we should discourage any kind of mass email (avoiding is impossible), and this modification would be interesting in that aspect. I solved my problem already, because it's open source, but I think it would be useful for someone else too, so my suggestion. I don't see a security problem here, but a policy compliance.
I think that if Roundcube aims to be used in Business this would be a nice feature. See for example, the Outlook Web Access, that is well accepted in the market. It doesn't have the contacts in the compose page (neither autocompletion ). Personally, I think that Roundcube is much better than OWA, though.
Jonathan Araújo Administrador de Infra-estrutura de TI Gerência de TI - INDG S.A.
-----Mensagem original----- De: dev-bounces+jonathanneto=indg.com.br@lists.roundcube.net [mailto:dev-bounces+jonathanneto=indg.com.br@lists.roundcube.net] Em nome de Michael Baierl Enviada em: terça-feira, 28 de outubro de 2008 12:27 Para: RoundCube Dev Assunto: Re: [RCD] RES: RES: Contacts gettiong exposed on html
till wrote:
Again, YOUR contacts show in the html source and you talk about security? Or am I mis-understanding an issue here.
I did not bring up the security issue nor did I test what happens in case of an LDAP directory.
No, it's easier and less expensive to pull it once and so to speak "cache" them in the source code/clientside and perform the auto-complete without a server request. Otherwise it will be slower and more expensive as you hit the database or your LDAP directory for every key-event.
So every time I compose a new mail all my 500 (imagine 1000 or 5000 contacts!) are downloaded to the client... instead of just my girlfriends contact via AJAX whom I want to send a mail to. Not very efficient on slow connections!
Mike
Ziba,
You have the same scenario of ours. I'm very interested in your patch. Would you share it?
Jonathan Araújo Administrador de Infra-estrutura de TI Gerência de TI - INDG S.A.
-----Mensagem original----- De: dev-bounces+jonathanneto=indg.com.br@lists.roundcube.net [mailto:dev-bounces+jonathanneto=indg.com.br@lists.roundcube.net] Em nome de Ziba Scott Enviada em: terça-feira, 28 de outubro de 2008 13:19 Para: RoundCube Dev Assunto: Re: [RCD] RES: RES: Contacts gettiong exposed on html
till wrote:
On Tue, Oct 28, 2008 at 3:57 PM, Michael Baierl mail@mbaierl.com wrote:
No, it's easier and less expensive to pull it once and so to speak "cache" them in the source code/clientside and perform the auto-complete without a server request. Otherwise it will be slower and more expensive as you hit the database or your LDAP directory for every key-event.
I agree that populating the contacts upfront can be faster and less expensive for many or maybe most installations. However, it isn't really an option for very large LDAP directories. Some directories simply will not return a full listing of all users.
In our environment, we have modified the autocomplete to do an ajax request because we wanted to provide our users with a list of their personal contacts combined with contacts pulled from a very large ldap system. We have plenty of extra LDAP server muscle, so repeated queries aren't a concern (and we're doing caching in php as a part of our patch).
Cheers, Ziba _______________________________________________ List info: http://lists.roundcube.net/dev/
Este documento pode incluir informação confidencial e de propriedade restrita do Instituto de Desenvolvimento Gerencial-INDG e apenas pode ser lido por aquele(s) a quem sido endereçado. Se você recebeu esta mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer opiniões ou informações contidas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com as do Instituto de Desenvolvimento Gerencial-INDG. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito do Instituto de Desenvolvimento Gerencial-INDG.
List info: http://lists.roundcube.net/dev/
till wrote:
In our environment, we have modified the autocomplete to do an ajax request because we wanted to provide our users with a list of their personal contacts combined with contacts pulled from a very large ldap system. We have plenty of extra LDAP server muscle, so repeated queries aren't a concern (and we're doing caching in php as a part of our patch).
Do you want to provide your patch
I really, really do. Unfortunately, the ldap part of it is very specific to our ldap schema. I will work on making it work for a more generic ldap address book.
To really make one patch work for both roundcube general and for people like us with wacky addressbooks, I'd like to make it a patch against devel-api and somewhere inside have a call to something like:
$RCMAIL->plugins->exec_hook('addressbook-autocomplete', array('search terms . . . .
Then address books could implement that call. Then that hook could be called either by ajax or to pre-populate the client like we do currently.
Thoughts?
Thanks, Ziba _______________________________________________ List info: http://lists.roundcube.net/dev/
On Tue, Oct 28, 2008 at 5:39 PM, Ziba Scott ziba@umich.edu wrote:
till wrote:
In our environment, we have modified the autocomplete to do an ajax request because we wanted to provide our users with a list of their personal contacts combined with contacts pulled from a very large ldap system. We have plenty of extra LDAP server muscle, so repeated queries aren't a concern (and we're doing caching in php as a part of our patch).
Do you want to provide your patch
I really, really do. Unfortunately, the ldap part of it is very specific to our ldap schema. I will work on making it work for a more generic ldap address book.
To really make one patch work for both roundcube general and for people like us with wacky addressbooks, I'd like to make it a patch against devel-api and somewhere inside have a call to something like:
$RCMAIL->plugins->exec_hook('addressbook-autocomplete', array('search terms . . . .
Then address books could implement that call. Then that hook could be called either by ajax or to pre-populate the client like we do currently.
Making it an "action" sounds about right to me.
Till
Thoughts?
Thanks, Ziba
List info: http://lists.roundcube.net/dev/
No, it's easier and less expensive to pull it once and so to speak "cache" them in the source code/clientside and perform the auto-complete without a server request. Otherwise it will be slower and more expensive as you hit the database or your LDAP directory for every key-event.
So every time I compose a new mail all my 500 (imagine 1000 or 5000 contacts!) are downloaded to the client... instead of just my girlfriends contact via AJAX whom I want to send a mail to. Not very efficient on slow connections!
Sounds like a case for HTML5 local storage . . .
till wrote:
On Tue, Oct 28, 2008 at 5:39 PM, Ziba Scott ziba@umich.edu wrote:
till wrote:
In our environment, we have modified the autocomplete to do an ajax request because we wanted to provide our users with a list of their personal contacts combined with contacts pulled from a very large ldap system. We have plenty of extra LDAP server muscle, so repeated queries aren't a concern (and we're doing caching in php as a part of our patch).
Do you want to provide your patch
I really, really do. Unfortunately, the ldap part of it is very specific to our ldap schema. I will work on making it work for a more generic ldap address book.
To really make one patch work for both roundcube general and for people like us with wacky addressbooks, I'd like to make it a patch against devel-api and somewhere inside have a call to something like:
$RCMAIL->plugins->exec_hook('addressbook-autocomplete', array('search terms . . . .
Then address books could implement that call. Then that hook could be called either by ajax or to pre-populate the client like we do currently.
Making it an "action" sounds about right to me.
Till
"Action" fits here very nicely, and that is indeed how we implemented it. I've posted a patch against svn trunk here:
http://trac.roundcube.net/ticket/1485531
In short it has:
client-side auto-complete.
order
Let me know if you'd like something changed.
Thinking some time down the road, it might be nice to see the mail/autocomplete action take advantage of devel-api. That is, if addressbooks were reimplemented as plugins. Is that desirable? If so, I'd be happy to work on that.
Addressbooks are pretty modular now, but we would love it if they were even more so using the devel-api plugin interface. We've got a horde read/write addressbook class. We haven't posted a patch for it because we assumed it's not appealing to most roundcube users, but we'd love to contribute it as a plugin for those who do care.
Thanks, Ziba
University of Michigan
List info: http://lists.roundcube.net/dev/