|  | escaping vs stored procedure | | |
| | | Fred |  |
|  Posted: Fri Aug 29, 2008 2:10 pm Post subject: Re: escaping vs stored procedure |  |
| |  | |
Dale wrote:
| Quote: | "Curtis" <dyer85@gmail.com> wrote in message
news:Zeqtk.851$482.655@trnddc06...
Dale wrote:
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g92p4u$nkt$1@registered.motzarella.org...
Fred wrote:
Jerry Stuckle wrote:
Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".
Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?
not a library function in MySQL
1) is that function contained in msql.dll?
2) why wouldn't MySQL have that functionality built into itself, maybe
activated by default with a switch? wouldn't that automatically prevent
a lot
of attacks? anybody who had the need could always switch it off
It is a library function in MySQL. But that doesn't mean it resides on
the server.
oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]
mysql_real_escape_string() is simply part of the MySQL C API, which is
compiled in with PHP. PHP is simply wrapping the C API.
It checks the connection's charset over an active connection (if that's
what you mean by "extra" traffic):
URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html
mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason not to
use mysql_real_escape_sting(), and is safe, if you know what you're doing.
You can abstract escaping in your own class if you don't have PDO
available.
this would be the second time you've disagreed with yourself. at least
this time you've done it in a seperate post rather than one sentence away
from when you foolishly said 'Nope. [no traffic]'.
pull your head out, jerry berry.
Why are you being so rude to someone who's trying to answer your
questions?
not my questions. and, i simply did not appreciate jerry's smug, sarcastic
remark to the op. that, and the fact that he was totally wrong with his
answer. the function does require a connection and in so much, generates
traffic...which was what the op wanted clarified. the answer is 'yes', not
the 'smarter than you' 'no' the op got from fairy.
btw, i use both prepared statements and a custom escaping class for my own
stuff.
|
can you post that? what inadequacies are in the php function?
| Quote: | i do, however, shutter at how frequently it is thrown around in this
ng that mysql_escape_string prevents sql injection. it doesn't! it only
helps. further, it doesn't work all the time.
|
have you got a link to a page that demonstrates where mysql_real_escape_string
falls down? I'd like to see the security hole demonstrated, just for the heck
of it
|
| |
| | | Dale | |
| | Posted: Fri Aug 29, 2008 5:08 pm Post subject: Re: escaping vs stored procedure | |
| | | |
"Fred" <Fred@notspam.not> wrote in message news:g99711$3k1$1@aioe.org...
| Quote: | Dale wrote:
"Curtis" <dyer85@gmail.com> wrote in message
news:Zeqtk.851$482.655@trnddc06...
Dale wrote:
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g92p4u$nkt$1@registered.motzarella.org...
Fred wrote:
Jerry Stuckle wrote:
Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".
Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?
not a library function in MySQL
1) is that function contained in msql.dll?
2) why wouldn't MySQL have that functionality built into itself,
maybe
activated by default with a switch? wouldn't that automatically
prevent
a lot
of attacks? anybody who had the need could always switch it off
It is a library function in MySQL. But that doesn't mean it resides
on
the server.
oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]
mysql_real_escape_string() is simply part of the MySQL C API, which is
compiled in with PHP. PHP is simply wrapping the C API.
It checks the connection's charset over an active connection (if that's
what you mean by "extra" traffic):
URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html
mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason not
to
use mysql_real_escape_sting(), and is safe, if you know what you're
doing.
You can abstract escaping in your own class if you don't have PDO
available.
this would be the second time you've disagreed with yourself. at least
this time you've done it in a seperate post rather than one sentence
away
from when you foolishly said 'Nope. [no traffic]'.
pull your head out, jerry berry.
Why are you being so rude to someone who's trying to answer your
questions?
not my questions. and, i simply did not appreciate jerry's smug,
sarcastic
remark to the op. that, and the fact that he was totally wrong with his
answer. the function does require a connection and in so much, generates
traffic...which was what the op wanted clarified. the answer is 'yes',
not
the 'smarter than you' 'no' the op got from fairy.
btw, i use both prepared statements and a custom escaping class for my
own
stuff.
can you post that? what inadequacies are in the php function?
|
no fred...but you can write your own.
| Quote: | i do, however, shutter at how frequently it is thrown around in this
ng that mysql_escape_string prevents sql injection. it doesn't! it only
helps. further, it doesn't work all the time.
have you got a link to a page that demonstrates where
mysql_real_escape_string
falls down? I'd like to see the security hole demonstrated, just for the
heck
of it
|
you can google for a myriad, but since you just want an example to see...
$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";
$query = db::execute($sql);
$valid = $query[0]['USEREXISTS'] ? true : false;
looks nice and fine, right? but, what if i submit this value to your
server...
<input name="id" value="0 OR 1 = 1" />
suddenly, i'm a valid user...or, i have access to something i'd not
otherwise be authorized for. mysql_real_escape_string won't help one bit in
instances like this. parameterized queries will. type-casting will, etc.,
etc..
i hate the naivety thrown about in this group when someone pipes up and says
that mysql_real_escape_string is all you need to prevent sql injection. not
only is this misleading, it is wrong. further, there are documented bugs
with it (google for some) and, worst of all, you are tying all of your
development db functionality to a specific implementation...leaving you
unable to scale. finally, it is NOT needed in order to secure your queries!
does that help? |
| |
| | | Curtis | |
| | Posted: Sat Aug 30, 2008 12:07 am Post subject: Re: escaping vs stored procedure | |
| | | |
Dale wrote:
| Quote: | "Fred" <Fred@notspam.not> wrote in message news:g99711$3k1$1@aioe.org...
Dale wrote:
"Curtis" <dyer85@gmail.com> wrote in message
news:Zeqtk.851$482.655@trnddc06...
Dale wrote:
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g92p4u$nkt$1@registered.motzarella.org...
Fred wrote:
Jerry Stuckle wrote:
Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".
Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?
not a library function in MySQL
1) is that function contained in msql.dll?
2) why wouldn't MySQL have that functionality built into itself,
maybe
activated by default with a switch? wouldn't that automatically
prevent
a lot
of attacks? anybody who had the need could always switch it off
It is a library function in MySQL. But that doesn't mean it resides
on
the server.
oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]
mysql_real_escape_string() is simply part of the MySQL C API, which is
compiled in with PHP. PHP is simply wrapping the C API.
It checks the connection's charset over an active connection (if that's
what you mean by "extra" traffic):
URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html
mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason not
to
use mysql_real_escape_sting(), and is safe, if you know what you're
doing.
You can abstract escaping in your own class if you don't have PDO
available.
this would be the second time you've disagreed with yourself. at least
this time you've done it in a seperate post rather than one sentence
away
from when you foolishly said 'Nope. [no traffic]'.
pull your head out, jerry berry.
Why are you being so rude to someone who's trying to answer your
questions?
not my questions. and, i simply did not appreciate jerry's smug,
sarcastic
remark to the op. that, and the fact that he was totally wrong with his
answer. the function does require a connection and in so much, generates
traffic...which was what the op wanted clarified. the answer is 'yes',
not
the 'smarter than you' 'no' the op got from fairy.
btw, i use both prepared statements and a custom escaping class for my
own
stuff.
can you post that? what inadequacies are in the php function?
no fred...but you can write your own.
i do, however, shutter at how frequently it is thrown around in this
ng that mysql_escape_string prevents sql injection. it doesn't! it only
helps. further, it doesn't work all the time.
have you got a link to a page that demonstrates where
mysql_real_escape_string
falls down? I'd like to see the security hole demonstrated, just for the
heck
of it
you can google for a myriad, but since you just want an example to see...
$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";
$query = db::execute($sql);
$valid = $query[0]['USEREXISTS'] ? true : false;
looks nice and fine, right? but, what if i submit this value to your
server...
input name="id" value="0 OR 1 = 1" /
suddenly, i'm a valid user...or, i have access to something i'd not
otherwise be authorized for. mysql_real_escape_string won't help one bit in
instances like this. parameterized queries will. type-casting will, etc.,
etc..
i hate the naivety thrown about in this group when someone pipes up and says
that mysql_real_escape_string is all you need to prevent sql injection. not
only is this misleading, it is wrong. further, there are documented bugs
with it (google for some) and, worst of all, you are tying all of your
development db functionality to a specific implementation...leaving you
unable to scale. finally, it is NOT needed in order to secure your queries!
does that help?
|
If you intval() ints, floatval() floats, etc., and
mysql_real_escape_string() strings, then you should be fine.
Alternatively, sprintf() also comes in quite handy in these situations.
--
Curtis |
| |
| | | Jerry Stuckle | |
| | Posted: Sat Aug 30, 2008 12:11 am Post subject: Re: escaping vs stored procedure | |
| | | |
Curtis wrote:
| Quote: | Dale wrote:
"Fred" <Fred@notspam.not> wrote in message news:g99711$3k1$1@aioe.org...
Dale wrote:
"Curtis" <dyer85@gmail.com> wrote in message
news:Zeqtk.851$482.655@trnddc06...
Dale wrote:
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g92p4u$nkt$1@registered.motzarella.org...
Fred wrote:
Jerry Stuckle wrote:
Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".
Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?
not a library function in MySQL
1) is that function contained in msql.dll?
2) why wouldn't MySQL have that functionality built into itself,
maybe
activated by default with a switch? wouldn't that automatically
prevent
a lot
of attacks? anybody who had the need could always switch it off
It is a library function in MySQL. But that doesn't mean it
resides on
the server.
oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]
mysql_real_escape_string() is simply part of the MySQL C API, which is
compiled in with PHP. PHP is simply wrapping the C API.
It checks the connection's charset over an active connection (if
that's
what you mean by "extra" traffic):
URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html
mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason
not to
use mysql_real_escape_sting(), and is safe, if you know what you're
doing.
You can abstract escaping in your own class if you don't have PDO
available.
this would be the second time you've disagreed with yourself. at
least
this time you've done it in a seperate post rather than one
sentence away
from when you foolishly said 'Nope. [no traffic]'.
pull your head out, jerry berry.
Why are you being so rude to someone who's trying to answer your
questions?
not my questions. and, i simply did not appreciate jerry's smug,
sarcastic
remark to the op. that, and the fact that he was totally wrong with his
answer. the function does require a connection and in so much,
generates
traffic...which was what the op wanted clarified. the answer is
'yes', not
the 'smarter than you' 'no' the op got from fairy.
btw, i use both prepared statements and a custom escaping class for
my own
stuff.
can you post that? what inadequacies are in the php function?
no fred...but you can write your own.
i do, however, shutter at how frequently it is thrown around in this
ng that mysql_escape_string prevents sql injection. it doesn't! it only
helps. further, it doesn't work all the time.
have you got a link to a page that demonstrates where
mysql_real_escape_string
falls down? I'd like to see the security hole demonstrated, just for
the heck
of it
you can google for a myriad, but since you just want an example to see...
$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";
$query = db::execute($sql);
$valid = $query[0]['USEREXISTS'] ? true : false;
looks nice and fine, right? but, what if i submit this value to your
server...
input name="id" value="0 OR 1 = 1" /
suddenly, i'm a valid user...or, i have access to something i'd not
otherwise be authorized for. mysql_real_escape_string won't help one
bit in instances like this. parameterized queries will. type-casting
will, etc., etc..
i hate the naivety thrown about in this group when someone pipes up
and says that mysql_real_escape_string is all you need to prevent sql
injection. not only is this misleading, it is wrong. further, there
are documented bugs with it (google for some) and, worst of all, you
are tying all of your development db functionality to a specific
implementation...leaving you unable to scale. finally, it is NOT
needed in order to secure your queries!
does that help?
If you intval() ints, floatval() floats, etc., and
mysql_real_escape_string() strings, then you should be fine.
Alternatively, sprintf() also comes in quite handy in these situations.
--
Curtis
|
ROFLMAO - the idiot doesn't understand that mysql_real_escape_string()
is meant to escape STRINGS, not numeric values.
Curtis, Dale/Steve/Barry and others is a real loser. He's really not
worth wasting your time on. He's just argue with you from his position
of total ignorance, yet insist he's correct and the rest of the world is
wrong.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
================== |
| |
| | | Michael Fesser | |
| | Posted: Sat Aug 30, 2008 2:10 pm Post subject: Re: escaping vs stored procedure | |
..oO(Dale)
| Quote: | you can google for a myriad, but since you just want an example to see...
$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";
|
WHERE Id = '$id'
Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().
Micha |
| |
| | | Dale | |
| | Posted: Sun Aug 31, 2008 1:40 am Post subject: Re: escaping vs stored procedure | |
| | | |
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g9aabo$m24$1@registered.motzarella.org...
| Quote: | Curtis wrote:
Dale wrote:
"Fred" <Fred@notspam.not> wrote in message news:g99711$3k1$1@aioe.org...
Dale wrote:
"Curtis" <dyer85@gmail.com> wrote in message
news:Zeqtk.851$482.655@trnddc06...
Dale wrote:
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g92p4u$nkt$1@registered.motzarella.org...
Fred wrote:
Jerry Stuckle wrote:
Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".
Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?
not a library function in MySQL
1) is that function contained in msql.dll?
2) why wouldn't MySQL have that functionality built into itself,
maybe
activated by default with a switch? wouldn't that automatically
prevent
a lot
of attacks? anybody who had the need could always switch it off
It is a library function in MySQL. But that doesn't mean it
resides on
the server.
oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]
mysql_real_escape_string() is simply part of the MySQL C API, which
is
compiled in with PHP. PHP is simply wrapping the C API.
It checks the connection's charset over an active connection (if
that's
what you mean by "extra" traffic):
URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html
mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason
not to
use mysql_real_escape_sting(), and is safe, if you know what you're
doing.
You can abstract escaping in your own class if you don't have PDO
available.
this would be the second time you've disagreed with yourself. at
least
this time you've done it in a seperate post rather than one sentence
away
from when you foolishly said 'Nope. [no traffic]'.
pull your head out, jerry berry.
Why are you being so rude to someone who's trying to answer your
questions?
not my questions. and, i simply did not appreciate jerry's smug,
sarcastic
remark to the op. that, and the fact that he was totally wrong with
his
answer. the function does require a connection and in so much,
generates
traffic...which was what the op wanted clarified. the answer is 'yes',
not
the 'smarter than you' 'no' the op got from fairy.
btw, i use both prepared statements and a custom escaping class for my
own
stuff.
can you post that? what inadequacies are in the php function?
no fred...but you can write your own.
i do, however, shutter at how frequently it is thrown around in this
ng that mysql_escape_string prevents sql injection. it doesn't! it
only
helps. further, it doesn't work all the time.
have you got a link to a page that demonstrates where
mysql_real_escape_string
falls down? I'd like to see the security hole demonstrated, just for
the heck
of it
you can google for a myriad, but since you just want an example to
see...
$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";
$query = db::execute($sql);
$valid = $query[0]['USEREXISTS'] ? true : false;
looks nice and fine, right? but, what if i submit this value to your
server...
input name="id" value="0 OR 1 = 1" /
suddenly, i'm a valid user...or, i have access to something i'd not
otherwise be authorized for. mysql_real_escape_string won't help one bit
in instances like this. parameterized queries will. type-casting will,
etc., etc..
i hate the naivety thrown about in this group when someone pipes up and
says that mysql_real_escape_string is all you need to prevent sql
injection. not only is this misleading, it is wrong. further, there are
documented bugs with it (google for some) and, worst of all, you are
tying all of your development db functionality to a specific
implementation...leaving you unable to scale. finally, it is NOT needed
in order to secure your queries!
does that help?
If you intval() ints, floatval() floats, etc., and
mysql_real_escape_string() strings, then you should be fine.
Alternatively, sprintf() also comes in quite handy in these situations.
--
Curtis
ROFLMAO - the idiot doesn't understand that mysql_real_escape_string() is
meant to escape STRINGS, not numeric values.
|
i'm the idiot? i said ppl here say the function cures all. i didn't say if
it was meant for strings or numerics. i gave an example of how sql injection
happens in spite of ones use of the function. PLUS, IDIOT...$id may be
intended as a number. it DOESN'T mean that's what i pass to your server! it
may also be a numeric...DOESN'T mean that's what i pass to your server!
oh yeah, NOW i can see why you never put up when i said you should give me
one of your urls to hack! you know i could!!! now, if i can just get you to
shut up.
| Quote: | Curtis, Dale/Steve/Barry and others is a real loser. He's really not
worth wasting your time on. He's just argue with you from his position of
total ignorance, yet insist he's correct and the rest of the world is
wrong.
|
yawn. the only one who consistently shows ignorance is YOU, fairy! i'll be
happy to bypass *your* security any day. let's see how good you are at
keeping me from spilling injections all over your shit. i'll make you look
like a pin cushion!
knob! |
| |
| | | Dale | |
| | Posted: Sun Aug 31, 2008 1:43 am Post subject: Re: escaping vs stored procedure | |
"Michael Fesser" <netizen@gmx.de> wrote in message
news:qvrib4t8nij9lpe86v6mj9blvmnfnkvqdt@4ax.com...
| Quote: | .oO(Dale)
you can google for a myriad, but since you just want an example to see...
$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";
WHERE Id = '$id'
Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().
|
that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific db
implementation.
cheers. |
| |
| | | Gordon Burditt | |
| | Posted: Sun Aug 31, 2008 4:05 am Post subject: Re: escaping vs stored procedure | |
| Quote: | Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().
that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific db
implementation.
|
But isn't there a problem: what mysql_real_escape_string() *needs
to do* depends on the specific db implementation, doesn't it? Aren't
what characters you *need* to escape in a string dependent on the
db implementation and the charset? |
| |
| | | Dale | |
| | Posted: Sun Aug 31, 2008 6:34 am Post subject: Re: escaping vs stored procedure | |
| | | |
"Gordon Burditt" <gordonb.m5zol@burditt.org> wrote in message
news:pNSdnSi86JI3qSfVnZ2dnUVZ_oPinZ2d@posted.internetamerica...
| Quote: | Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().
that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific
db
implementation.
But isn't there a problem: what mysql_real_escape_string() *needs
to do* depends on the specific db implementation, doesn't it? Aren't
what characters you *need* to escape in a string dependent on the
db implementation and the charset?
|
that's not what i'm saying. you should be abstracting your db layer and
implementing the specifics needed based on what db you go with. as it is,
the majority of db's out there can be handled with odbc and ansi
sql...inclusive of much of that information. further, that information does
not change often, if at all. that can be hard-coded into an include which
takes away from having to create traffic between the app and the db...which
that function does.
the 'specific implementation' you are talking about is mysql. you aren't
using mysql interfaces to hit oracle. how mysql itself is
implemented/configured is a moot point. i'm talking about different db's,
not different configs of mysql.
make sense? |
| |
| | | Michael Fesser | |
| | Posted: Sun Aug 31, 2008 6:54 pm Post subject: Re: escaping vs stored procedure | |
| | | |
..oO(Dale)
| Quote: | "Michael Fesser" <netizen@gmx.de> wrote in message
news:qvrib4t8nij9lpe86v6mj9blvmnfnkvqdt@4ax.com...
.oO(Dale)
you can google for a myriad, but since you just want an example to see...
$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";
WHERE Id = '$id'
Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().
that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific db
implementation.
|
I use PDO with my own wrapper class around it, but still use a lot of
MySQL-specific features and SQL enhancements, simply because they are
convenient and often make life a lot easier for me. I don't plan to run
my scripts on another system, a recent LAMP is simply a requirement for
my framework.
Micha |
| |
|
|
