Jump to content

Prepared statements and slashes ... Please advise.


jtorral

Recommended Posts

Ok.  So I just started using prepared statements.  One issue I ran into is that after inserting say "abc's" into the table with a prepared statement when I read that row and display it, it shows as abc\'s 

 

I have to use stripslashes on the variable before displaying it. 

 

I thought that with magic quotes. off this would not be a problem. Am I going to have to strip slashes on all fields now? Is there another way around it?

 

here is my phpinfo for reference

 

magic_quotes_gpc Off Off

magic_quotes_runtime Off Off

magic_quotes_sybase Off Off

 

And compile options

 

Configure Command './configure' '--host=i686-redhat-linux-gnu' '--build=i686-redhat-linux-gnu' '--target=i386-redhat-linux' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--without-mime-magic' '--without-sqlite' '--with-libxml-dir=/usr' '--with-xml' '--with-mhash=shared' '--with-mcrypt=shared' '--with-apxs2=/usr/sbin/apxs' '--without-mysql' '--without-gd' '--without-odbc' '--disable-dom' '--disable-dba' '--without-unixODBC' '--disable-pdo' '--disable-xmlreader' '--disable-xmlwriter' '--disable-json'

 

Thanks

 

JT

 

 

 

Link to comment
Share on other sites

Are the \ characters actually in the data in the database table (when you look directly using your favorite database management tool) or only when you retrieve the data?

 

Which database class you are using in your code? Any chance you are calling some filter/clean function that is also escaping the data?

Link to comment
Share on other sites

I looked in the database and the value was stored with the \'s

 

However, prior to inserting it was sanitized with

 

 

  $thisval = strip_tags($thisval);

  $thisval = mysql_real_escape_string($thisval);

 

 

I re ran it without calling those functions and it worked. Stupid question. But, now that I use prepared statements, does that mean I no longer need to call these functions?

 

Thanks

 

Link to comment
Share on other sites

With prepared statements, an 's' field type will be escaped for you, so you would not use mysql_real_escape_string() on the data.

 

strip_tags() has nothing to do with sql injection and it would be up to how you are using the data if you need to use strip_tags() on it.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.