web-erp-developers

[WebERP-developers] AllowAnyone No Problem

[Phil D. <ph...@lo...>]

It seems that Tim's "critical vulnerability" issue identified relates to 
the use of $AllowAnyone which circumvents the normal authentication 
mechanism.

These are the scripts where $AllowAnyone is set to true.

1. webERP/GLTrialBalance_csv.php://$AllowAnyone = true;

YES - this script was a problem as previously advised when it was first 
identified. This script should be removed from any webERP installation.

2. webERP/Logout.php:$AllowAnyone=True; /* Allow all users to log off  */

It seems reasonable that anyone should be allowed to log off?

3. webERP/RecurringSalesOrdersProcess.php:$AllowAnyone = true;

This script can be run by anyone too and it just processes any recurring 
order templates into orders based on the frequency of recurrence ... you 
can run this as many times as you like - there is no output and it is 
intended to be run from cron using wget.

4. webERP/api/api_php.php:    $AllowAnyone = true;

This allows the api to run - there is separate authentication required. 
No problem

5. webERP/MailInventoryValuation.php:$AllowAnyone = true;

This scripts sends an inventory valuation email to the users defined in 
the script - no output to anyone externally - no risk to anyone - also 
intended to be run from cron

6. webERP/MailSalesReport_csv.php:$AllowAnyone = true;

This scripts sends an email of a sales report as a csv to the users 
defined in the script - no output to anyone externally - no risk to 
anyone - also intended to be run from cron

7. webERP/report_runner.php:$AllowAnyone = true;

This script sends an email of a sales report to the users defined in the 
script - no output to anyone externally - no risk to anyone - also 
intended to be run from cron

8. webERP/MailSalesReport.php:$AllowAnyone = true;

This scripts sends an email of a sales report to the users defined in 
the script - no output to anyone externally - no risk to anyone - also 
intended to be run from cron


So .... IMHO - none of these last 7 scripts represent a security risk 
(only the GLTrialBalance_csv.php - already identified). Maybe they 
present a potential spam risk.
I am keen to avoid the propagation of FUD on the mailing lists and 
forums - hence my perhaps heavy handed moderation. I do particularly 
watch Tim given his alternative agenda. However, his knowledgeable 
contributions have been good more recently. Perhaps he didn't look at 
what these scripts do, he is normally pretty smart. Perhaps I should 
have given him the benefit of the doubt.

Hopefully we have a clear reporting mechanism for reporting issues that 
people may worry about publicly identifying for fear of exposing other 
users webERP installations. icedlava's suggestion was that the email - 
sec...@we... be used and this sends email to Exson, icedlava and 
myself - so we can have a look privately before alerting the community 
as necessary.

-- 
Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

Re: [WebERP-developers] AllowAnyone No Problem

[gilberto d. s. a. <gs...@gm...>]

+1 from me.
may be this url [1] from django could help to bring ideas, procedures and
standard procedures like you propose.
See details that djangoproject.com is not using sourceforge.net but one own
domain. IMO i set -1 for sourceforge lists is advertising on foot pages and
on lists these ads inside of lot of places are handled like spam.

Thanks for your time.

[1]
https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/


2014-03-14 23:00 GMT-03:00 Phil Daintree <ph...@lo...>:

> It seems that Tim's "critical vulnerability" issue identified relates to
> the use of $AllowAnyone which circumvents the normal authentication
> mechanism.
>
> These are the scripts where $AllowAnyone is set to true.
>
> 1. webERP/GLTrialBalance_csv.php://$AllowAnyone = true;
>
> YES - this script was a problem as previously advised when it was first
> identified. This script should be removed from any webERP installation.
>
> 2. webERP/Logout.php:$AllowAnyone=True; /* Allow all users to log off  */
>
> It seems reasonable that anyone should be allowed to log off?
>
> 3. webERP/RecurringSalesOrdersProcess.php:$AllowAnyone = true;
>
> This script can be run by anyone too and it just processes any recurring
> order templates into orders based on the frequency of recurrence ... you
> can run this as many times as you like - there is no output and it is
> intended to be run from cron using wget.
>
> 4. webERP/api/api_php.php:    $AllowAnyone = true;
>
> This allows the api to run - there is separate authentication required.
> No problem
>
> 5. webERP/MailInventoryValuation.php:$AllowAnyone = true;
>
> This scripts sends an inventory valuation email to the users defined in
> the script - no output to anyone externally - no risk to anyone - also
> intended to be run from cron
>
> 6. webERP/MailSalesReport_csv.php:$AllowAnyone = true;
>
> This scripts sends an email of a sales report as a csv to the users
> defined in the script - no output to anyone externally - no risk to
> anyone - also intended to be run from cron
>
> 7. webERP/report_runner.php:$AllowAnyone = true;
>
> This script sends an email of a sales report to the users defined in the
> script - no output to anyone externally - no risk to anyone - also
> intended to be run from cron
>
> 8. webERP/MailSalesReport.php:$AllowAnyone = true;
>
> This scripts sends an email of a sales report to the users defined in
> the script - no output to anyone externally - no risk to anyone - also
> intended to be run from cron
>
>
> So .... IMHO - none of these last 7 scripts represent a security risk
> (only the GLTrialBalance_csv.php - already identified). Maybe they
> present a potential spam risk.
> I am keen to avoid the propagation of FUD on the mailing lists and
> forums - hence my perhaps heavy handed moderation. I do particularly
> watch Tim given his alternative agenda. However, his knowledgeable
> contributions have been good more recently. Perhaps he didn't look at
> what these scripts do, he is normally pretty smart. Perhaps I should
> have given him the benefit of the doubt.
>
> Hopefully we have a clear reporting mechanism for reporting issues that
> people may worry about publicly identifying for fear of exposing other
> users webERP installations. icedlava's suggestion was that the email -
> sec...@we... be used and this sends email to Exson, icedlava and
> myself - so we can have a look privately before alerting the community
> as necessary.
>
> --
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>



-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

[WebERP-developers] AllowAnyone No Problem

[web e. <web...@ya...>]

Phil,

What spreads FUD about a project is your censoring any 
debate about such issues. Even now you rejected my post explaining how 
once a user doesn't need to log in to gain access to the database they 
can generate errors revealing damaging information about the webERP 
implementation.

Typically, you make cryptic comments about my 
"alternative agenda" and then don't back this up with any fact. What on 
earth does "alternative agenda" mean?? What agenda?? Please specify if 
you are going to make these allegations. As a webERP developer I earn my
 living from the good name of webERP. What would I have to gain by 
damaging it? It is your stupid vendetta against me that damages the 
project. Contributions should be accepted on a basis of the merit of the
 code, not on some silly personal vendetta of yours, however you 
repeatedly reject my contributions. It seems to me it is you who damage 
the project and you who spreads what you call FUD.

Tim