I think I'v gotten a quite grasp of what sql injection is. However preventing them still looks like a misery to me.

I will be glad if someone can clarify the following terms I was able to know during my study of these topic and their REAL EFFECT plus strength and differences.

-Mysql_real_escape_string()

-addslashes()

-prepared statement

-preg_match( , )


Please just drop your comment, the little you know may clarify my confusion.

All of these generally sterilize unwanted characters in your SQL statement. These unwanted characters like say "\x00, \n, \r, \, " can break your queries and cause you lots of trouble; so you sterilize your statments by telling the server to disregard them all and treat your input as dead text.

mysql_real_escape_string(): makes a text safe for input into the database. You dont need to worry about the details of the characters. The server determines what characters to remove.


add_slashes(): makes text safe for input to the database by escaping "'" and """ characters so mysql does not interpret these as delimiters.

preg_match() : a search function. you could use this to check if your text contains unsafe characters, before removing them with str_replace or something...


That said; You really should consult google first before posting questions like this. I am sure answers to your question abound in search engines.

Thanks larisoft. Like I said, I was confused but your simple definitions clarified this.

However, the addslashes() escapes characters like ' and " by adding a \ before them right? So

-- I'm a numb --

Will be saved as

-- I\'m a numb --

And thus prevent possible attack of '1=1' ish and rest...

Now, if that is right like I read, does it mean it is a must to use stripslashes() for every input field addslashes() has been used for? In order to return the data as it was inputted?


Concerning mysql_real_escape_string(), I learnt it is a command that executes at the database depending on the preset character set. Since it takes note of the field's data type, then for numeric fields like INT won't be a problem as it would accept only Integers. But what of fields like Varchar, Text which may include characters like ' and " meaning it should be part of the character set.

If the character set allows these malicious characters then what guarantee does mysql_real_escape_string has?




Pardon me if I am a real numb! But I guess pouring out my thought on this could make someone easily figure out where I'm getting it all wrong or even figuring it out myself. I'm not just convinced of my thought.

Thanks for the contribution bro. Xpectn more...

Why worry about php when you have a super duper c# environment you can use to save data and still protect it from hackers and thieves? And it's even quite simple to understand!

Seems that's an option gimakon but right now, php is my knowledge area.

tohero:
Thanks larisoft. Like I said, I was confused but your simple definitions clarified this.

However, the addslashes() escapes characters like ' and " by adding a \ before them right? So

-- I'm a numb --

Will be saved as

-- I\'m a numb --

And thus prevent possible attack of '1=1' ish and rest...

Now, if that is right like I read, does it mean it is a must to use stripslashes() for every input field addslashes() has been used for? In order to return the data as it was inputted?


Concerning mysql_real_escape_string(), I learnt it is a command that executes at the database depending on the preset character set. Since it takes note of the field's data type, then for numeric fields like INT won't be a problem as it would accept only Integers. But what of fields like Varchar, Text which may include characters like ' and " meaning it should be part of the character set.

If the character set allows these malicious characters then what guarantee does mysql_real_escape_string has?




Pardon me if I am a real numb! But I guess pouring out my thought on this could make someone easily figure out where I'm getting it all wrong or even figuring it out myself. I'm not just convinced of my thought.

Thanks for the contribution bro. Xpectn more...

MySQL real escape string escapes all what it knows is illegal in the SQL query while same cannot be said for addslashes which only operates on a limited set of characters....you can be pretty sure of no injection if you use the database native method...

some links
a) http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string --- shows you can still get "injected" if you use addslashes by making use of some weird character sets.. Chris shifflet is a PHP security expert


b) http://dev.mysql.com/doc/refman/5.1/en/mysql-real-escape-string.html -- official doc from MySQL

c ) http://php.net/manual/en/function.addslashes.php has some nice notes ABOUT when not to use the function.



above all,mysql* functions are no longer maintained, don't be suprised if funny stuffs still happens,use MySQLi* or pdo

gimakon:
Why worry about php when you have a super duper c# environment you can use to save data and still protect it from hackers and thieves? And it's even quite simple to understand!

C# feels strong while using it; but php still pay bills here in Nigeria.

Thanks jregz. The first article goes a long way.
And of course, mysqli is one of two option for the future now.
Thanks once again, Thanks also, larisoft