escaping vs stored procedure

if I use mysql_real_escape_string on all INSERT or UPDATE queries, then would
a stored procedure provide any extra protection?

the user has to be granted UPDATE and/or INSERT privileges anyway.

Also, I've just noticed this from the manual: "mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".

So for every occasion that I call php's mysql_real_escape_string(), that
results in traffic over the socket (or pipe) to the MySQL server, right?

"Fred" <Fred@notspam.not> wrote in message news:g91gas$k1f$1@aioe.org...
> if I use mysql_real_escape_string on all INSERT or UPDATE queries, then
> would
> a stored procedure provide any extra protection?
>
> the user has to be granted UPDATE and/or INSERT privileges anyway.

why would it? that totally depends on how your 'user' accesses the db -
whether via your app (in which you define what 'user' will hit the db) or
via some other interface where the 'user' can select which 'user' to login
as.

this is a mute point when it comes to sproc's that take string as arguments
anyway! either way, you are going to have to apply your own logic
*somewhere* in order to make sure the data isn't harmful.

> Also, I've just noticed this from the manual: "mysql_real_escape_string()
> calls MySQL's library function mysql_real_escape_string".
>
> So for every occasion that I call php's mysql_real_escape_string(), that
> results in traffic over the socket (or pipe) to the MySQL server, right?

i've always balked at the notion of using mysql_real_escape_string. first,
not only does it give you a false sence of security (documented cased where
it DOESN'T prevent injection), it also ties your *validation* routines to
mysql. there are simply not many things that need to be done in order to
make sure the data you are receiving for your db is not going to fuck up the
works.

however, yes, it would give you said traffic as it is locale-specific in
what it escapes. you should use, if at all and if you must,
mysql_escape_string instead. your locale has NOTHING to do with the locale
of the end-user.

just my 0.02 usd.

Fred wrote:
> if I use mysql_real_escape_string on all INSERT or UPDATE queries, then would
> a stored procedure provide any extra protection?
>

It depends on what you do in the stored procedure. If you do additional
checking of the data, yes. Otherwise, no.

> the user has to be granted UPDATE and/or INSERT privileges anyway.
>
> 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.

> So for every occasion that I call php's mysql_real_escape_string(), that
> results in traffic over the socket (or pipe) to the MySQL server, right?
>

Nope. This is performed locally in the client library. No
communications over the link is performed.

And this is the correct function to use. It will escape characters
based on the current charset being used by the connection.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(Dale)

>"Fred" <Fred@notspam.not> wrote in message news:g91gas$k1f$1@aioe.org...
>
>> Also, I've just noticed this from the manual: "mysql_real_escape_string()
>> calls MySQL's library function mysql_real_escape_string".
>>
>> So for every occasion that I call php's mysql_real_escape_string(), that
>> results in traffic over the socket (or pipe) to the MySQL server, right?
>
>i've always balked at the notion of using mysql_real_escape_string. first,
>not only does it give you a false sence of security (documented cased where
>it DOESN'T prevent injection), it also ties your *validation* routines to
>mysql.

Sure, but do you change your DBMS as often as your underpants?

Use PDO and prepared statements instead and you don't have to worry
about such things at all.

Micha

Answer is here - http://vids365.com/main?escaping+vs+stored+procedure

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

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. That's why, in order to access ANY MySQL functions, you
must have the MySQL libraries installed on your system.

And no, it's not in msql.dll - that's not a MySQL library.

As for not having it built in - it can't. For one thing, it's not a
part of the SQL standard. But mainly because in some languages the
quotes have a different meaning.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Michael Fesser" <netizen@gmx.de> wrote in message
news:8469b4t3n0rdl54f0n638eult4m1ttqa7h@4ax.com...
> .oO(Dale)
>
>>"Fred" <Fred@notspam.not> wrote in message news:g91gas$k1f$1@aioe.org...
>>
>>> Also, I've just noticed this from the manual:
>>> "mysql_real_escape_string()
>>> calls MySQL's library function mysql_real_escape_string".
>>>
>>> So for every occasion that I call php's mysql_real_escape_string(), that
>>> results in traffic over the socket (or pipe) to the MySQL server, right?
>>
>>i've always balked at the notion of using mysql_real_escape_string. first,
>>not only does it give you a false sence of security (documented cased
>>where
>>it DOESN'T prevent injection), it also ties your *validation* routines to
>>mysql.
>
> Sure, but do you change your DBMS as often as your underpants?

well, if you're a consultant i'm sure you don't want to have to start
everything from scratch. i'm sure you'd probably have a good sized library
of functional code that you'd reuse. if you tie your application to one db,
that kind of limits not only your flexibility, it also means you'll have to
reprogram your db interface when you get a client who uses, say...oracle, or
teradata, or db II or whatever.

so yes, one should be *prepared* to change DBMS at any time with minimal
change to code.

> Use PDO and prepared statements instead and you don't have to worry
> about such things at all.

most any db suite of functions in php allow you to use prepared
statements...why tie yourself to pdo?

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g921ks$spo$1@registered.motzarella.org...
> Fred wrote:
>> if I use mysql_real_escape_string on all INSERT or UPDATE queries, then
>> would
>> a stored procedure provide any extra protection?
>>
>
> It depends on what you do in the stored procedure. If you do additional
> checking of the data, yes. Otherwise, no.
>
>> the user has to be granted UPDATE and/or INSERT privileges anyway.
>>
>> 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.
>
>> So for every occasion that I call php's mysql_real_escape_string(), that
>> results in traffic over the socket (or pipe) to the MySQL server, right?
>>
>
> Nope. This is performed locally in the client library. No communications
> over the link is performed.
>
> And this is the correct function to use. It will escape characters based
> on the current charset being used by the connection.

once again jerry, you're a complete IDIOT. let me put your two statements
together:

"This is performed locally in the client library"
"based on the current charset being used by the connection"

so, in fact, Y.E.S. is the correct answer. moron!

"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. 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.