471,066 Members | 967 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,066 software developers and data experts.

addslashes/mysql_real_escape_string

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
Mar 27 '08 #1
13 3334
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.
Mar 27 '08 #2
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/
Mar 27 '08 #3
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
Mar 27 '08 #4
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.
Mar 27 '08 #5
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
==================

Mar 27 '08 #6
..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
Mar 27 '08 #7
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
Mar 27 '08 #8
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
Mar 27 '08 #9
On Mar 27, 9:39*am, ndlarsen <use...@ionline.dkwrote:
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?
Mar 27 '08 #10
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.
Mar 27 '08 #11
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
==================

Mar 27 '08 #12
Gabest wrote:
On Mar 27, 9:39 am, ndlarsen <use...@ionline.dkwrote:
>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
==================

Mar 27 '08 #13
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
Mar 28 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by leegold2 | last post: by
reply views Thread by Bob Bedford | last post: by
4 posts views Thread by Jan Pieter Kunst | last post: by
2 posts views Thread by Marcus | last post: by
2 posts views Thread by Cruella DeVille | last post: by
15 posts views Thread by =?ISO-8859-1?Q?J=F8rn?= Dahl-Stamnes | last post: by
5 posts views Thread by Gilles Ganault | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.