Protecting against malicious user input in forms

[alhefner]

I want to protect my site against attack from malicious users who try to attack the site via input forms.

Will this function do the job?


function GetVar($name, $source, $default = "", $protect = true){
$var = "";
$souce = strtoupper($source);
switch($source){
default:
case "REQUEST":
$var = isset($_REQUEST[$name]) ? ($protect ? mysql_real_escape_string($_REQUEST[$name]) : $_REQUEST[$name]) : $default;
break;
case "GET":
$var = isset($_GET[$name]) ? ($protect ? mysql_real_escape_string($_GET[$name]) : $_GET[$name]) : $default;
break;

case "POST":
$var = isset($_POST[$name]) ? ($protect ? mysql_real_escape_string($_POST[$name]) : $_POST[$name]) : $default;
break;
}
return $var;
}

Much tahnks in advance! I know the gurus here will help!

[justgowithit]

Escaping user input is a great start, but you could make things a lot more thorough, functional and user-friendly by validating input and incorporating user error notices into your forms.

Is your site form-intensive? What type of forms are you dealing with?

[alhefner]

It will be pretty form intensive. There will be search forms with much of the possible input in the form of drop down lists populated from the database. Users will also be providing input to store in the database using fairly large text areas and a few smaller text fields.

I will need to allow some latitude in the input as the site is sort of a classified advertising kind of thing. I am pretty sure I'll strip all html tags and perhaps go to bbcode for some formatting.

My main issue is to ensure that there isn't any successful SQL injection and that no user can fool the system into displaying code source.

All input will be in $_POST() variables. I don't like long variable strings on the URL.

[wige]

Post is the way to go, but it won't give any additional security - it is fairly simple to manipulate these fields. Dropdowns can also be altered, so bear in mind that all fields submitted must be validated.

One thing that I have found useful is to process the input fields into variables, then delete the input string, before doing any other processing - this protects against any temptation to utilize the unvalidated input. Another technique I have found useful is putting all validation methods into an external script that is called by all of the form processing scripts. This makes it possible to correct issues and increase your error-handling capabilities for the entire site by editing a single file.

[MrGamm]

Take note...

That's still not going to protect you if your database queries are structured improperly...

This is a good cheat sheet...

SQL Injection Cheat Sheet (http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/)

Notice the section...

"Very useful for bypassing, magic_quotes() and similar filters"

[DaveSawers]

That's a useful cheat sheet, just when I needed it. Thanks.

I have used mysql_real_escape_string to clean up input and it works just fine as long as MySQL is actually installed and used on the server. My current development project, intended for use on client intranet sites, makes use of either SQL Server or Oracle as a database engine. First time we tried to install it on a client server for test purposes, it crashed because they had no MySQL.

The clean up line was only used in a single function (good design) so it was simple to take out to get the application working. Before going live, I'm going to have to be a lot more sophisticated about security.

Damn those hackers!

[Web-Design-Guy]

Have you considered a 'honeypot spam trap' - hidden (via css) input field that must remain unfilled in order for the form to be submitted. I hear bots can't resist filling in all fields.