Re: [Dolibarr-dev] Vulnerabilities

[Philip Lehmann-Böhm]

Hi, thank you for the answer.
Ok,
why is this an option? This is just not optional. Thanks for pointing me
to it, I wouldn't have found it. :) The whole column "pass" should just
be removed.
How is the password crypted? I assume a salted and hashed password?

How comes that you use an own function to escape query parameters and
not the buildin ones?
Take for example this one: admin/facture.php

line 161: $sql.= " WHERE nom = '".$db->escape($value)."'";

line 194:     $sql.= " VALUES ('".$value."', '".$type."',
".$conf->entity.", ";

$value is the same variable, one time escaped, one time not. Maybe this
is dangerous, maybe not. If you'd use prepared statements and not string
concatenation, this would not have slipped through.

No offense meant, this is just important. :)

Am 03.11.2013 22:11, schrieb Destailleur Laurent:
> There is already an option to have password crypted into database (menu
> security - encrypt password)
> 
> Also you suggest to use a method to sanitized sql request parameters.
> Using such a function to clean sql parameters is already done. The
> function is called db->escape (a method of mysql.class.php). Port to use
> it step by step was started few years ago.
> 
> In a future the continuous integration platform should also be able to
> cry when escaping parameters will be forgotten. 
> 
> 
> 
> 2013/11/3 Philip Lehmann-Böhm <address@hidden
> <mailto:address@hidden>>
> 
>     Hi,
> 
>     (sorry, I don't know how to reply directly to the existing thread:
>     http://lists.nongnu.org/archive/html/dolibarr-dev/2013-10/msg00003.html
>     )
> 
>     This just blew my mind a bit. In this topic, especialy the denial of
>     starting to use parametrized queries.
>     And that the password is stored in plain text in the database is a
>     no go.
> 
>     And the statement, that everything of the quoted website has been fixed
>     is not true. I run a freshly installed Dolibarr 3.4.1 and the passwords
>     are indeed available in plain text!
> 
>     I'm willing to help here and this is what I propose:
>     - Are there plans to drop the plain password column? Has this already
>     happened in the next version? This goes to much in the core of Dolibarr,
>     so I won't be able to patch this in a meaningful timespan.
> 
>     - Not using prepared statements is a no go as well. I'd add support for
>     them in the mysql.class.php (not familiar with the others) with a
>     function like this:
>     function parametrizedQuery($query, $params,
>     $usesavepoint=0,$type='auto')
>     And then start to port the code to use it step by step and making some
>     pull requests.
> 
>     What do you think? Would this be a way to go?
> 
>     Best Regards
>     Philip
> 
>     _______________________________________________
>     Dolibarr-dev mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> 
> 
> 
> 
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>