PHP 4.3.3RC3 was just released, hopefully this will be the final release
candidate prior to the final release. Please test this release as much
possible so that any new/critical bugs maybe uncovered and resolved before
the final. If you do find such bugs (hopefully you won't) be sure to label
them as RC3 bugs.
I would like to ask that all developers refrain from making commits to the 4_3
tree until 4.3.3 final is released, unless a patch addresses a critical
issue. Critical issues are defined as the following:
- Security Fixes
- Fixes for bugs introduced in 4.3.3X releases
- Fixes for bugs that break backwards compatibility with older versions.
Ilia
"Ilia Alshanetsky" ilia@prohost.org wrote in message
news:200308071447.03285.ilia@prohost.org...
I would like to ask that all developers refrain from making commits to
the 4_3 tree until 4.3.3 final is released, unless a patch addresses a
critical issue. Critical issues are defined as the following:
- Security Fixes
What about hacking somehow the sqlite library to disallow chained queries
(or at least do it optionally)?
This behavior is huge security hole, allow to the cracker drop ur database
using simple select where query.
moshe
What about hacking somehow the sqlite library to disallow chained queries
(or at least do it optionally)?This behavior is huge security hole, allow to the cracker drop ur database
using simple select where query.
How is this a security hole?
regards,
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/
"Derick Rethans" derick@php.net wrote in message
news:Pine.LNX.4.53.0308140932320.12247@jdi.jdimedia.nl...
What about hacking somehow the sqlite library to disallow chained
queries
(or at least do it optionally)?This behavior is huge security hole, allow to the cracker drop ur
database
using simple select where query.How is this a security hole?
http://www.phpbuilder.com/mail/php-developer-list/2003022/0062.php
moshe
What about hacking somehow the sqlite library to disallow chained
queries
(or at least do it optionally)?
If you are unable or unwilling to verify the safety of your input,
use a database that supports params + binding (like Firebird :-))
Any input obtained from the client should be considered unsafe
(== tainted in Perl) and should be checked for correctness first.
In the described case, casting the value to a number if it's
expected to be numerical or putting quotes around it if it's expected
to be a string value will solve your problem. Disallowing chained
queries will prevent every developer from ever using it.
Ard
Ard Biesheuvel wrote:
Disallowing chained
queries will prevent every developer from ever using it.
thats why i suggested earlier to maybe make it a runtime
configurable feature that defaults to 'off'
--
Hartmut Holzgraefe <hartmut@php.net
First of all this discussion bares to relevance to the 4.3.3 release as sqlite
is NOT part of this release. Secondly this is just plain silly. PHP is not
and is not responsible for validating input. If the user chooses not to and
consequently leaves their scripts vulnreable to SQL injection it is their
fault and their fault alone.
Ability to chain queries is an extremely useful feature that most database
systems support (even MySQL as of version 4.0). To cripple or disable such
functionality would be absolute idiocy not to mention break backwards
compatibility to older versions where this was possible. Adding more run-time
directives (as suggested by Hartmut Holzgraefe ) is a bad idea as it makes
writing portable code extremely difficult as each system may have a
drastically different behavior due to an ini option.
Ilia
Right, and in the end this should be done on a per-site basis through the
input filtering mechanism I added to PHP5 a while ago.
-Rasmus
First of all this discussion bares to relevance to the 4.3.3 release as sqlite
is NOT part of this release. Secondly this is just plain silly. PHP is not
and is not responsible for validating input. If the user chooses not to and
consequently leaves their scripts vulnreable to SQL injection it is their
fault and their fault alone.
Ability to chain queries is an extremely useful feature that most database
systems support (even MySQL as of version 4.0). To cripple or disable such
functionality would be absolute idiocy not to mention break backwards
compatibility to older versions where this was possible. Adding more run-time
directives (as suggested by Hartmut Holzgraefe ) is a bad idea as it makes
writing portable code extremely difficult as each system may have a
drastically different behavior due to an ini option.Ilia