Jump to content

mysql_real_escape_string using


UnknownPlayer

Recommended Posts

You should use mysql_real_escape_string() on any "text" input that could potentially have unsafe content. This includes ALL text input that comes from the user $_POST, $_COOKIE, and $_GET (also $_REQUEST which you shouldn't use though). You might as well throw $_SESSION in there if you happen to store user data in session and then use it in a query later.

 

But, if you are hard-coding values that are used in queries you don't need to use mysql_real_escape_string() on it since you should be specifying the data so it is safe. But, there should be no harm in running it on that data too.

 

EDIT: As floridaflatlander stated you would only need this for "text" data (e.g. varchar fields). If you have ints, floats, etc. then verify that data is in the appropriate format. Then there are date fields which require different validation. Just make sure the input matches the database field type.

Link to comment
Share on other sites

I use this function on every field, number, text etc.. for safety..

 

Whenever possible, it's more secure to make sure the value is what you expect. Numbers, for example, could be validated with the ctype_digit() function:

http://php.net/manual/en/function.ctype-digit.php

 

If you expect a number and you get something else, it's better to let the user know about the error instead of trying to insert it into the database.

 

 

Also, you may want to re-read mjdamato response; especially the part about mysql_real_escape_string() only being effective with "text" inputs.

Link to comment
Share on other sites

It doesnt work with number fields ?

Like date str in 10 chars ?

 

If it is a date, don't you have to validate that it is in a valid date format to being with? If so, what is the purpose of using mysql_real_escape_string()? Just because you can do something doesn't mean you should do it. I don't know how "expensive" mysql_real_escape_string() is in terms of performance, but I see no reason to unnecessarily run it on data that I have already confirmed as being safe/validated for the type being stored: int, float, date, etc.

 

My preference is to review each value being used in a query and make a conscious decision about what needs to be done to it rather than just do a blanket process. The latter can provide a false sense of security and make you less prone to look for possible problems.

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.