> Wasn't addslashes() designed to escape shell commands and
> mysql_escape_string() for MySQL queries?
That's right.
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Aug 15, 2003 at 11:19:47AM +0200, Ard Biesheuvel wrote:
> 'SELECT ... WHERE id='. (int)$id
Even shorter :
'SELECT ... WHERE id='. $id+0
> 'SELECT ... WHERE name=" '.addslashes($name).' " '
Wasn't addslashes() designed to escape shell commands and
mysql_escape_string() for MySQL qu
> The problem is string compositing SQL queries. With a SQL command
> builder interface, query hacks don't occur. Right now, string
> compositing mysql queries with unvalidated input often results in just
> minor bugs, as from what I hear the mysql extention can't do chained
> queries yet, so the
This one time, at band camp, "Steven Brown" <[EMAIL PROTECTED]> wrote:
> I'll let it drop, but I think your views will result in dangerous
> interfaces and I hope you reconsider. If you enable chained queries in
> the mysql extension as-is for example, it will enable a massive flood of
> hacking.
On Thu, 14 Aug 2003, Rasmus Lerdorf wrote:
> On Thu, 14 Aug 2003, Steven Brown wrote:
> > I found an example of passing unvalidated input into a SQL query, I
> > didn't say it would lead to an exploit. The point was, yes, even you
> > guys make this mistake. It's not a "Well, you should have lea
Hello Steven,
Friday, August 15, 2003, 8:54:53 AM, you wrote:
SB> Btw, it's also never adequate validation to let users inject their own
SB> SQL, even in a SELECT. They might add impossibly complex stuff to the
SB> where clause and cause your database to wedge for days, or add a 'or 1 =
SB> 1'
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2003 11:15 PM
> To: Steven Brown
> Cc: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Re: PHP 4.3.3RC3 Released
> On Thu, 14 Aug 2003, Steven Brown wrote:
> &
On Thu, 14 Aug 2003, Steven Brown wrote:
> > -Original Message-
> > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 14, 2003 10:53 PM
> > To: Steven Brown
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [PHP-DEV] Re: PHP 4.3.3RC3
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2003 10:53 PM
> To: Steven Brown
> Cc: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Re: PHP 4.3.3RC3 Released
>
>
> On Thu, 14 Aug 2003, Steven Brown wrote
On Thu, 14 Aug 2003, Steven Brown wrote:
> I found an example of passing unvalidated input into a SQL query, I
> didn't say it would lead to an exploit. The point was, yes, even you
> guys make this mistake. It's not a "Well, you should have learned to
> write secure code" type of issue. Everyon
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2003 10:37 PM
> To: Steven Brown
> Cc: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Re: PHP 4.3.3RC3 Released
>
>
> On Thu, 14 Aug 2003, Steven Brown wrote:
>
> -Original Message-
> From: John Coggeshall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2003 10:17 PM
> To: Steven Brown
> Cc: 'moshe doron'; PHP Internals
> Subject: RE: [PHP-DEV] Re: PHP 4.3.3RC3 Released
>
>
> > It's in
On Thu, 14 Aug 2003, Steven Brown wrote:
> It's insanely easy to make such mistakes though, and php.net is full of
> such problems (I found 2 in 15 minutes), so it's not a 'stupid
> developer' issue, as you guys make the same mistakes, and are extremely
> experienced.
That's interesting considerin
> It's insanely easy to make such mistakes though, and php.net is full of
> such problems (I found 2 in 15 minutes), so it's not a 'stupid
I'd like to hear where these problems are, off list of course.
> minor bugs, as from what I hear the mysql extention can't do chained
> queries yet, so there'
; To: moshe doron; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Re: PHP 4.3.3RC3 Released
> 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 valid
+1.
This is no bug in PHP, it is not a security flaw in PHP; it is a problem
in your code. PHP shouldn't police your lax security because you can't
be bothered with it.
Can we drop this thread now? :-)
--Wez.
On Thu, 14 Aug 2003, Derick Rethans wrote:
> On Thu, 14 Aug 2003, moshe doron wrote:
"Marcus BöRger" <[EMAIL PROTECTED]> wrote in message
> md> http://www.phpbuilder.com/mail/php-developer-list/2003022/0062.php
>
> Bullshit.
>
> If the cracker can change one of your sql statements he already has access
to
> your machine. In that case he wouldn't bother changing your sql
statements
"Derick Rethans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Thu, 14 Aug 2003, moshe doron wrote:
>
> > 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 cra
"Derick Rethans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> uhm? SQLite definitely needs a seperator there.
yep, i got confused by the ' style (sybase one).
moshe.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"Marc Boeren" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> > that's the point. if the cracker can change only the end of
> > the query, it's not so usefull for him (he can maximum get other id)
>
> How about a form of dos:
>
> '...where id = '.$id
>
> with $id = '23129 or 1'
>
>
"Steven Brown" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> > -Original Message-
> > From: Derick Rethans [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 14, 2003 12:33 AM
> > To: moshe doron
> > Cc: [EMAIL PR
Alle 11:18, giovedì 14 agosto 2003, moshe doron ha scritto:
> > How about a form of dos:
> >
> > '...where id = '.$id
> >
> > with $id = '23129 or 1'
> >
> > this will select all entries in the table which could result in
> > DoS...
> >
> > So, ultimately this problem is the coders responsibility.
Cesare D'Amico wrote:
Why not stopping support for s then? Drop $_GET, $_POST and
$_REQUEST! They're EVIL!
That way everyone is *really* safe from sql injection :-)
thats what PERLs "TAINT" mode is for ;)
(see for http://gunther.web66.com/FAQS/taintmode.html)
--
Hartmut Holzgraefe <[EMAIL
On Thu, 14 Aug 2003, moshe doron wrote:
> > E.g.,
> >
> > $id = "0; drop bar";
> > lamesql_query("select foo from bar where id = $id");
> >
> that's the mysql way
> with sybase style (used by sqlite), the is no need to separator, makes the
> detection even harded.
uhm? SQLite definitely needs
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2003 12:33 AM
> To: moshe doron
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Re: PHP 4.3.3RC3 Released
>
>
> On Thu, 14 Aug 2003, moshe doron wrote:
>
"Derick Rethans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Thu, 14 Aug 2003, moshe doron wrote:
>
> > the question is what is the common php programing habit.
> > sinse there is no public recommendation on the manual (fix me here) or
> > someware else, i assume thats the he
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
On Thu, 14 Aug 2003, Ilia Alshanetsky wrote:
> First of all this discussion bares to relevance to the 4.3.3 release as sqlite
> is NOT part of this release. Se
On Thu, 14 Aug 2003, moshe doron wrote:
> the question is what is the common php programing habit.
> sinse there is no public recommendation on the manual (fix me here) or
> someware else, i assume thats the hebit is not always do verify the data
> and u can't blame the php users.
Well, that's n
Steven Brown wrote:
How is this a security hole?
E.g.,
$id = "0; drop bar";
lamesql_query("select foo from bar where id = $id");
this is also possible with oracle, oci8 and other database extensions,
mysql ist the only one where i'm sure about that chaining is *not*
supported
so the actual secur
Hello moshe,
Thursday, August 14, 2003, 10:41:16 AM, you wrote:
md> "Derick Rethans" <[EMAIL PROTECTED]> wrote in message
md> news:[EMAIL PROTECTED]
>> On Thu, 14 Aug 2003, moshe doron wrote:
>>
>> > What about hacking somehow the sqlite library to disallow chained
md> queries
>> > (or at least
On Thu, 14 Aug 2003, moshe doron wrote:
>
> "Marcus BöRger" <[EMAIL PROTECTED]> wrote in message
> > md> http://www.phpbuilder.com/mail/php-developer-list/2003022/0062.php
> >
> > Bullshit.
> >
> > If the cracker can change one of your sql statements he already has access to
> > your machine. In
On Thu, 14 Aug 2003, moshe doron wrote:
> 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?
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2003 1:29 AM
> To: moshe doron
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Re: PHP 4.3.3RC3 Released
>
>
> On Thu, 14 Aug 2003, moshe doron wrote:
>
&
> -Original Message-
> From: Marc Boeren [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2003 1:08 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Re: PHP 4.3.3RC3 Released
>
>
>
> > that's the point. if the cracker can change only th
> that's the point. if the cracker can change only the end of
> the query, it's not so usefull for him (he can maximum get other id)
How about a form of dos:
'...where id = '.$id
with $id = '23129 or 1'
this will select all entries in the table which could result in DoS...
So, ultimately t
Steven Brown wrote:
[...] Mysql
doesn't allow (AFAIK) command chaining for this reason to lessen the
potential damage.
the PHP mysql extension does not support command chaining for the
simple reason that it is not supported by the MySQL C API itself
prior to the client library that comes with MyS
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 i
"Hartmut Holzgraefe" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Steven Brown wrote:
> >>How is this a security hole?
> >
> >
> > E.g.,
> >
> > $id = "0; drop bar";
> > lamesql_query("select foo from bar where id = $id");
>
> this is also possible with oracle, oci8 and other data
On Thu, 14 Aug 2003, Steven Brown wrote:
> E.g.,
>
> $id = "0; drop bar";
> lamesql_query("select foo from bar where id = $id");
Well Do'h, how is this a security problem?
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future
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 <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing Lis
Sorry:
That code should have been:
$id = some_escape_string_function( intval( "0; drop bar" ) );
if( $id > 0 )
{
lamesql_query( "select foo from bar where id = '$id'" ) );
}
else
{
// Error?
}
Just wa
On Thursday, Aug 14, 2003, at 00:45 US/Pacific, Steven Brown wrote:
On Thu, 14 Aug 2003, moshe doron wrote:
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 s
No :)
If you are really worried about these kind of attacks, I suggest you
read one of the many articles that explains how to write a secure
PHP application.
You can also take it further and write a "user input" filter using the
framework that Rasmus added for this purpose (mostly from a XSS poin
43 matches
Mail list logo
