views:

242

answers:

7

I have a form with many fields...

The action is set to a php page which queries mysql...

Should I sanitize with mysql_real_escape_string every single variable? Or can I ignore sanitizing drop-lists and radios for instance?

Also, besides mysql_real_escape_string, what else should I do to prevent attacks?

Thanks

+1  A: 

You only need to use mysql_real_escape_string to escape strings prior to using them in SQL statements, to prevent SQL Injection attacks.

In addition, when taking data out of your database and writing it out as HTML, you should consider using htmlspecialchars or strip_tags to prevent cross-site scripting attacks.

Justin Ethier
Better to use htmlspecialchars() I think. strip_tags is not always working as intended.
FractalizeR
neither htmlspecialchars nor mysql_real_escape_string work as a magic pill under all conditions, please see http://stackoverflow.com/questions/110575/do-htmlspecialchars-and-mysql-real-escape-string-keep-my-php-code-safe-from-injec
Cheekysoft
A: 

Here is a derived table approach that can avoid SQL Injection http://beyondrelational.com/blogs/madhivanan/archive/2010/05/14/derived-table-new-approach-to-avoid-sql-injection.aspx

Madhivanan
incredible stupid approach
Col. Shrapnel
So, do you think the method is open to SQL Injection?
Madhivanan
Yes it is still open. I've not evaluated Method 1 but in Method 2 1=1 would pass and return unfiltered values from the SQL. If those were medical appointments, joined to patient records and you were EXPECTING to pass in Patient_ID = nnnnn... but I called it with 1=1, that would be injection and Method 2 would fail - I'd get a complete list of every patient and their appointments. You set up a single case SQL Injection and built a function that stops that one case.
Stephanie Page
Yes. That would anywany avoid updating the table
Madhivanan
Try with any DML or DDL statements
Madhivanan
+4  A: 

You must check selects and radio buttons too. Anyone can create their own HTML form and post it to your script. The Firefox extension Web Developer Toolbar even has an option to convert selects to text inputs.

You can also check that the posted data only contains correct values. For example, if you have a radio button, make sure that the posted form only contain one of the valid values.

You should of course only run mysql_real_escape_string on variables that you are going to put into MySQL. If saving to file, using on the commandline or anything other, there are more apropriate functions and solutions.

Emil Vikström
remember mysql_real_escape_string is only safe to use when the escaped value is delimited by single quotes in the resultant sql statement. Even better: forget about string escaping and just use bound sql parameters.
Cheekysoft
+1  A: 

Any variable sent from the client can't be consider as safe and valid. If you are using them in query you should always sanitize them.

HoLyVieR
what about variables that weren't sent from the client?
Col. Shrapnel
+2  A: 

In general it is trivial to form a POST request outside of the browser and so bypass any restrictions the drop down list (for example) may have imposed on possible values.

Because of this you should always treat user data as hostile and error-prone and put as much validation and protection on the server-side as possible.

Paolo
A: 

You only have to sanitize the fields that you don't want an attacker to hijack. The data can be form any source, not just your page. mysql_real_escape_string is good for any value that will concatenated into a query, but I "sanitize" everything. To me, "sanitize" means more than handling injection attacks, it includes any field validation as well (sting length, numeric, valid date, empty, etc).

KM
+2  A: 

Another bunch of ignorant answers. Camran, you're attracting it like magnet.

You have to understand that mysql_real_escape_string has nothing to do with forms and radios, with checking and sanitizing.
And it does not prevent attacks.

It is merely a string escaping function. It escapes a data that going to be inserted into SQL query string as a string data.

SQL query is a little program. With it's own syntax. You must follow that syntax, not because of "attacks" but because of it's just a syntax. And, of course, these rules do not depend on the source of data! Radio button, html form or browser - all doesn't matter!

And it works only with strings. Not with numbers nor identifiers.

Here is my answer on how to handle an SQL query: http://stackoverflow.com/questions/2993027/in-php-when-submitting-strings-to-the-db-should-i-take-care-of-illegal-characters/2995163#2995163

Col. Shrapnel