SQL Injection and user input sanitization

[RedMaster]

Hey ppl,

 

I'm working on a application where security is very important. Not only to keep bad people from doing malicious things, but to also protect the database and the server from being broken do to an innocent mistake or something by an end user.

 

I've got the input for the email and phone numbers covered. What I need to know right now is how to protect other more general form fields such as name, address, which I think need to be somewhat flexible in what characters they accept, from being used to cause the program to "break", execute arbitrary code, or perform some type of SQL Injection attack on the db. So I'm wondering what techniques would one recommend on guarding against exploitation in this area?

 

Would simply requiring input to match general regular expressions do the trick?

Would I need something that strips out all potential harmful characters?

 

I wrote this small funct. for sanitizing the name and address fields but it seems too simple. Input appreciated!

Thanks!!

function safe($string) {

  return filter_var($string, FILTER_SANITIZE_STRING);

}

[RedMaster]

Could not find an edit function for my original post so this reply is the updated code I'm considering...

function safe($string) {

  $v = strip_tags($string);
  return filter_var($v, FILTER_SANITIZE_STRING);

}

[Azu]

Just run mysql_real_escape_string on the input, that will make it safe.

[Eric_Ryk]

Just run mysql_real_escape_string on the input, that will make it safe.

Yeah, mysql_real_escape_string is the way to go. Make sure that if magic quotes is on that you strip quotes before calling real escape.

[Azu]

Never use magic quotes. If it is on turn it off. If your hosting company refuses to let you turn it off, find another one.

They are officially deprecated, and will be completely removed in PHP6.

[RedMaster]

Well all that sounds fine for moving data into a database but what about the security of the scipt in general? Namely preventing users from being able to throw a bunch of wierd characters into the text fields and causing the script to get choked on them.

 

I've been using regular expressions to allow only certain characters in some fields (or else the data is thrown out). But it isn't going so smooth for my address data. Is there any one thing you'd reccomend that I could employ to take care of potentially dangerous user-provided data?

[Eric_Ryk]

Well all that sounds fine for moving data into a database but what about the security of the scipt in general? Namely preventing users from being able to throw a bunch of wierd characters into the text fields and causing the script to get choked on them.

 

I've been using regular expressions to allow only certain characters in some fields (or else the data is thrown out). But it isn't going so smooth for my address data. Is there any one thing you'd reccomend that I could employ to take care of potentially dangerous user-provided data?

Could you provide an example as to how that's screwing up your script?

[RedMaster]

Well all that sounds fine for moving data into a database but what about the security of the scipt in general? Namely preventing users from being able to throw a bunch of wierd characters into the text fields and causing the script to get choked on them.

 

I've been using regular expressions to allow only certain characters in some fields (or else the data is thrown out). But it isn't going so smooth for my address data. Is there any one thing you'd reccomend that I could employ to take care of potentially dangerous user-provided data?

Could you provide an example as to how that's screwing up your script?

I'm not saying it is, I'm just wanting to prevent it. The site this will be on may be subject to expolit attempts by random people looking to bring down the site in question.

[Batosi]

Umm if you dont want html to be allowed just do htmlspecialchars() on the input.

[Eric_Ryk]

Umm if you dont want html to be allowed just do htmlspecialchars() on the input.

You can do that, as well as strip_tags if you want to just remove them period.

 

Really you won't run into too much of a problem if you use those two, though ideally regular expression checks are best. An address for example might be composed of the following:

 

/^[A-Z0-9.\- ']+$/i

 

So even though you said you have some complex fields, an address should not be one of them.

[RedMaster]

Umm if you dont want html to be allowed just do htmlspecialchars() on the input.

You can do that, as well as strip_tags if you want to just remove them period.

 

Really you won't run into too much of a problem if you use those two, though ideally regular expression checks are best. An address for example might be composed of the following:

 

/^[A-Z0-9.\- ']+$/i

 

So even though you said you have some complex fields, an address should not be one of them.

Yeah see i was having problems building a regex for that field. I kept wanting to keep it flexible; i.e. let users include special characters such as #, and & incase they randomly wanted to. I'll try ur sample regex. Thanks.

[d.shankar]

Use

mysql_real_escape_string to ward against SQL Injection Attacks

strip_tags to ward against XSS Attacks.

[Azu]

lol there's that echo again..

[Eric_Ryk]

Never use magic quotes. If it is on turn it off. If your hosting company refuses to let you turn it off, find another one.

They are officially deprecated, and will be completely removed in PHP6.

I forgot to get to this point earlier. There is no point in changing hosts if they refuse to change, the reason being is that you can effectively cancel them out inside of your script. There's no point in going through all that hassle if all it takes is a few lines to make a wrapper function.

[Azu]

The thing is, chances are if your host won't even let you disable magic_quotes, it's probably one of those stupid hosts that is going to keep using extremely outdated versions of PHP forever and ever..

[Eric_Ryk]

The thing is, chances are if your host won't even let you disable magic_quotes, it's probably one of those stupid hosts that is going to keep using extremely outdated versions of PHP forever and ever..

I can see what you're getting at, though you can never be too sure. Most of the time it's just ignorance on their part thinking that having it enabled is some form of security.