Need advice on sql injection protection and why my function won't work.

[sptrsn]

I haven't had a problem with sql injection yet, but I'm scarred to death. 

 

I didn't do any form data validation as I was building my site. I'm just now starting to learn how.

 

Magic_quotes is turned on at my host.

I know about htmlspecialchars and mysql_real_escape_string and stripslashes and htmlentities.

In testing each of these, it seems they all miss one thing or another.

 

so, I created an array of words and characters that I can't for the life of me imagine anyone would ever need on any form in my site, that I THINK addresses most if not all of the really bad things. But hey... I'm new to this. So here is my array and using print_r() it looks pretty good.

 

$badstuff = array('select','delete','update','insert','drop','=',';','"','\'','<','>','/');

Array ( [0] => select [1] => delete [2] => update [3] => insert [4] => drop [5] => select [6] => delete [7] => update [8] => insert [9] => drop [10] => = [11] => ; [12] => " [13] => ' [14] => < [15] => > [16] => / )

 

My str_ireplace() function works fine within the code, but I'd like to create a function using str_ireplace(). I am failing miserably.

 

Here is my function that doesn't work...

function strip($string){
	return str_ireplace($badstuff,"",$string);
}

 

Here below..... the first line, that uses the function does NOT work.

The second line that just uses str_replace() function works fine.

 

echo strip($string).'<br>';
echo str_ireplace($badstuff,"",$string)

 

Can anyone tell me why my function does not work? I've read and watched 20 tutorials and just can't see the problem.

 

Thanks for any input.

 

[RussellReal]

put the $badstuff array inside the function, php isn't like javascript, in that everything in the global scope is accessible within other scopes.

 

if it is necessary to leave $badstuff on the outside of the function's scope..

 

use global $badstuff;

 

in the function

 

like this:

 

function strip($string){
global $badstuff;
return str_ireplace($badstuff,"",$string);
}

 

but!!! Just to put this out there.. for mostly everything, you don't need to remove 'update' 'drop' etc from the inputs to sanitize them..

 

thats bad.. mysql_real_escape_string will ofcourse catch all unescaped quotation marks, and that is the only way they can inject stuff into your sql query.. if they break one of your quotes, and THEN do some UPDATE/DROP etc..

 

and furthermore, they'd also need to know your table names, field names, etc, sql injection is a big problem, yes.. but, don't worry too much about it, aslong as you sanitize with mysql_real_escape_strings, and typecast your expected numerical inputs

 

E.G.

 

$id = (int) $_POST['id'];

 

you should be pretty much fine

[sptrsn]

ahahahaha! You're a genius. Never occurred to me that had to be inside the function. That worked great.

 

I'm very encouraged to hear you say that mysql_real_esacpe_strings() is very effective.

In the few tests I did, it didn't seem like it removed enough of the scarry stuff.

 

I should probably give up on this and just make sure mysql_real_escape_strings is working, cuz that would be easy.

 

thanks again.

[KevinM1]

Don't use 'global' to pass values into a function.  Pass those values through the function's argument list.  NEVER use 'global' at all for anything, ever.

 

Also, what do you mean by mysql_real_escape_string missing certain things?  How are you using it?  What do you consider to be 'scary' that it's letting through?

[codeprada]

Mysqp_real_escape_string works to some effect but it's still vulnerable to SQL injections. You really don't need to be manually checking replacing anything in your query. Look into Prepared Statements, which are immune to injections if used properly. Offered by MySQLi and PDO. One reason why you should drop MySQL.

[LiquidFusi0n]

thats bad.. mysql_real_escape_string() will ofcourse catch all unescaped quotation marks, and that is the only way they can inject stuff into your sql query.. if they break one of your quotes, and THEN do some UPDATE/DROP etc..

 

and furthermore, they'd also need to know your table names, field names, etc, sql injection is a big problem, yes.. but, don't worry too much about it, aslong as you sanitize with mysql_real_escape_strings(), and typecast your expected numerical inputs

 

As already stated mysql_real_escape_string() can be bypassed in a couple of different circumstances, of course use it, but do not rely on it. Also they need to know your table names, field names etc... etc... We are not living so much in the days of MySQL 4 now are we. We have a lovely table called Information_Schema that can provide the attackers with that information... to state don't worry about it too much is a fallacy. Worry about it, and make sure you prevent it.

 

--LiquidFusi0n 

[RussellReal]

can you show me an example of an sql injection attempt that would bypass mysql_real_escape_string... how do you inject bad SQL into an SQL query if quotes are being escaped? How do you break out of the value isolation..

 

I guess sure you should always be worried about sql injection, but don't worry about it to the extent that nothing gets done, and if you're on mysql, do with what you're given..

 

and to expand on what I said originally..

 

"bad stuff" like 'update', 'select' etc, could be part of what the user wants to submit, a non-malicious user.. thats why you shouldn't remove update and select, etc.. You simply need to worry about the apostrophes..

 

until one of these guys supply a MySQL query that will bypass mysql_real_escape_string, you should assume its atleast plausibly safe..

 

@NightSlayr, why not to use global? Deprecation?

 

I don't see that as such a big reason to say 'never ever NEVER EVER OIJSA:LKJAS:LKAJSA: EVER EVER" lol

 

as far as I'm concerned.. both of those major attacks on my reply, doesn't make all that much sense.

 

I'd understand the deprecation worries, to make sure your code doesn't break, but thats coder preference.. as far as the assumption that

mysql_real_escape_string

is that insecure to cause so much worry, on the other hand, makes me wonder where you're getting this information from..