addslashes/mysql_real_escape_string

[ndlarsen]

Hello.

It's been a while since I used php. Since then magic quotes has been
deprecated and will be removed when php 6.0 hits. My question is, what
should I be using when submitting data to a database instead? Which is
better for security reasons, addslashes() or mygql_real_escape_string()?

Thanks you.

Regards

ndlarsen

[Lars Eighner]

In our last episode, <47***********************@news.sunsite.dk>, the lovely
and talented ndlarsen broadcast on comp.lang.php:

Hello.

It's been a while since I used php. Since then magic quotes has been
deprecated and will be removed when php 6.0 hits. My question is, what
should I be using when submitting data to a database instead? Which is
better for security reasons, addslashes() or mygql_real_escape_string()?

See the best practices example in the article on mysql_real_escpae_string in
the manual. For portability you need to check for whether magic quotes are
on and reverse them if they are. If portability is not a concern and it is
your own machine, you can turn magic quotes off and save a few steps.

mysql_real_escpae_string requires a database connection and will attempt to
establish one if it cannot find an explicit link or the default previous
link. The most convenient time, then, to apply it is just before entering
the data in the database.
--
Lars Eighner <http://larseighner.com/us****@larseighner.com
Countdown: 299 days to go.

[Toby A Inkster]

ndlarsen wrote:

My question is, what should I be using when submitting data to a
database instead? Which is better for security reasons, addslashes() or
mygql_real_escape_string()?

Depends on what database you're using. mysql_real_escape_string() is a
good solution if you're using MySQL, because it uses encoding-specific
techniques.

Some of the other database modules provide similar functions. For those
that don't, addslashes() can be used as a last resort.

The best solution though is to use PDO and prepared statements.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 20:40.]

Best... News... Story... Ever!
http://tobyinkster.co.uk/blog/2008/03/23/hypnotist/

[ndlarsen]

I appreciate your reply.

Depends on what database you're using. mysql_real_escape_string() is a
good solution if you're using MySQL, because it uses encoding-specific
techniques.

Sorry about that, I should have mentioned that it is a MySQL database.

The best solution though is to use PDO and prepared statements.

You sort of lost me here.

Regards

ndlarsen

[Lars Eighner]

In our last episode, <47***********************@news.xs4all.nl>, the lovely
and talented Erwin Moller broadcast on comp.lang.php:

No matter if you are updating, or inserting, or selecting: You ALWAYS must
prepare for the worst.

This is, of course, the right answer. The database can be attacked through
a query string that you intend for SELECT --- which if it worked as you
intended, would only obtain data from the database. But of course a
malicious value could turn your SELECT query into anything else, so you must
escape any value that could possibly be tainted --- and generally escaping
every value whatsoever is best.

--
Lars Eighner <http://larseighner.com/us****@larseighner.com
Countdown: 299 days to go.

[Jerry Stuckle]

ndlarsen wrote:

Again I appreciate your replies.
I guess I chose the wrong words before, probably because I knew what I
meant and expected that everybody else would as well. Now, as none is
capable of mind reading, this is not so. ;)
I just tested the "best practices" code from the php manual and it did
what I expected it to - that is, not modifying the data and submitting
it to the db unaltered. So if I were to submit data to a db, a string
containing "jnjsdf'jn/ljknv\knns", it would be submitted to the db as
such and I could retrieve it without the need to strip the string from
any sort of characters, right? At least so it seems from following code:

Read up on mysql_real_escape_string(). It does modify the data as it's
being sent to the database - but the data is modified in a predictable
way (i.e. to take care of embedded quotes, etc.). The result when
retrieved from the database is just as you put it in there.

Add databases require some modification of the data to store special
characters. But if you do the modification properly, the data is
retrieved without modification. MySQL has a function which does this
for you; some others don't.

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

[Michael Fesser]

..oO(ndlarsen)

>The best solution though is to use PDO and prepared statements.

You sort of lost me here.

See the PDO section in the PHP manual. It's really not that complicated,
but much more powerful and flexible.

Micha

[ndlarsen]

Jerry Stuckle wrote:

Read up on mysql_real_escape_string(). It does modify the data as it's
being sent to the database - but the data is modified in a predictable
way (i.e. to take care of embedded quotes, etc.). The result when
retrieved from the database is just as you put it in there.

Add databases require some modification of the data to store special
characters. But if you do the modification properly, the data is
retrieved without modification. MySQL has a function which does this
for you; some others don't.

Right, I think I got it now. Some of the testing code I used made it
appear as if the string was automatically stripped of backslashes when I
retrieved it from the database/table.
If I run mysql_real_escape_string() on a string prior to inserting it
into a database/table, it is submitted to the database modified (with
backslashes escaping special characters). If I retrieve that same string
from the database/table, it is still modified and I need to strip the
string of the backslashes, perhaps with stripslashes()?

Thank you.

Regards

ndlarsen

[ndlarsen]

Michael Fesser wrote:

See the PDO section in the PHP manual. It's really not that complicated,
but much more powerful and flexible.

Will do, thanks.

ndlarsen

[Gabest]

On Mar 27, 9:39*am, ndlarsen <[e-mail]:

Hello.

It's been a while since I used php. Since then magic quotes has been
deprecated and will be removed when php 6.0 hits. My question is, what
should I be using when submitting data to a database instead? Which is
better for security reasons, addslashes() or mygql_real_escape_string()?

Thanks you.

Regards

ndlarsen

I don't want to go offtopic, but mysql_real_escape_string serously
leaks memory for me. Using MDB2's quote function it runs out of my
allowed 200MB in a minute. If I just comment out
mysql_real_escape_string inside the escape function there is no leak.
Any idea?

[Lars Eighner]

In our last episode, <47***********************@news.sunsite.dk>, the lovely
and talented ndlarsen broadcast on comp.lang.php:

If I run mysql_real_escape_string() on a string prior to inserting it
into a database/table, it is submitted to the database modified (with
backslashes escaping special characters). If I retrieve that same string
from the database/table, it is still modified and I need to strip the
string of the backslashes, perhaps with stripslashes()?

No. The database will handle this. One of the reasons
mysql_real_escape_string requires a database link is so that it can properly
escape the string in light of the database character set.
Mysql_real_escape_string provides data in a form the database can understand.
In fact, the database stores that data by a somewhat different escape
scheme and undoes its escapes when it returns data.

--
Lars Eighner <http://larseighner.com/us****@larseighner.com
Countdown: 298 days to go.

[Jerry Stuckle]

ndlarsen wrote:

Jerry Stuckle wrote:

>Read up on mysql_real_escape_string(). It does modify the data as
it's being sent to the database - but the data is modified in a
predictable way (i.e. to take care of embedded quotes, etc.). The
result when retrieved from the database is just as you put it in there.

>Add databases require some modification of the data to store special
characters. But if you do the modification properly, the data is
retrieved without modification. MySQL has a function which does this
for you; some others don't.

Right, I think I got it now. Some of the testing code I used made it
appear as if the string was automatically stripped of backslashes when I
retrieved it from the database/table.
If I run mysql_real_escape_string() on a string prior to inserting it
into a database/table, it is submitted to the database modified (with
backslashes escaping special characters). If I retrieve that same string
from the database/table, it is still modified and I need to strip the
string of the backslashes, perhaps with stripslashes()?

Thank you.

Regards

ndlarsen

No. mysql_real_escape_string() only modifies the string for storage in
the database (and no, it does not do the same thing as addslashes()).

What you retrieve from the database will be identical to what you had
before calling mysql_real_escape_string().
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Gabest wrote:

On Mar 27, 9:39 am, ndlarsen <[e-mail]:

>Hello.

It's been a while since I used php. Since then magic quotes has been
deprecated and will be removed when php 6.0 hits. My question is, what
should I be using when submitting data to a database instead? Which is
better for security reasons, addslashes() or mygql_real_escape_string()?

Thanks you.

Regards

ndlarsen

I don't want to go offtopic, but mysql_real_escape_string serously
leaks memory for me. Using MDB2's quote function it runs out of my
allowed 200MB in a minute. If I just comment out
mysql_real_escape_string inside the escape function there is no leak.
Any idea?

I have never had a memory leak from mysql_real_escape_string(). What
version are you running?

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

[ndlarsen]

I appreciate your help and patience, I really do. I got it now, it
seemed that I messed something up big time in my test scripts which
caused me to believe that things were otherwise. After flushing the
table and starting over things made more sense to me. Thanks yet again.

ndlarsen