Storing parts of user data in files for preventing SQL injection

Question

I am new to web programming and have been exploring issues related to web security.

I have a form where the user can post two types of data - lets call them "safe" and "unsafe" (from the point of view of sql).

Most places recommend storing both parts of the data in database after sanitizing the "unsafe" part (to make it "safe").

I am wondering about a different approach - to store the "safe" data in database and "unsafe" data in files (outside the database). Ofcourse this approach creates its own set of problems related to maintaining association between files and DB entries. But are there any other major issues with this approach, especially related to security?

UPDATE: Thanks for the responses! Apologies for not being clear regarding what I am considering "safe" so some clarification is in order. I am using Django, and the form data that I am considering "safe" is accessed through the form's "cleaned_data" dictionary which does all the necessary escaping.

For the purpose of this question, let us consider a wiki page. The title of wiki page does not need to have any styling attached with it. So, this can be accessed through form's "cleaned_data" dictionary which will convert the user input to "safe" format. But since I wish to provide the users the ability to arbitrarily style their content, I can't perhaps access the content part using "cleaned_data" dictionary.

Does the file approach solve the security aspects of this problem? Or are there other security issues that I am overlooking?

Answer 1

What do you consider "safe" and "unsafe"? Are you considering data with the slashes escaped to be "safe"? If so, please don't.

Use bound variables with SQL placeholders. It is the only sensible way to protect against SQL injection.

Answer 2

Splitting your data will not protect you from SQL injection, it'll just limit the data which can be exposed through it, but that's not the only risk of the attack. They can also delete data, add bogus data and so on.

I see no justification to use your approach, especially given that using prepared statements (supported in many, if not all, development platforms and databases).

That without even entering in the nightmare that your approach will end up being.

In the end, why will you use a database if you don't trust it? Just use plain files if you wish, a mix is a no-no.

Answer 3

SQL injection can targeted whole database not only user, and it is the matter of query (poisoning query), so for me the best way (if not the only) to avoid SQL injection attack is control your query, protect it from possibility injected with malicious characters rather than splitting the storage.

Answer 4

You know the "safe" data you're talking about? It isn't. It's all unsafe and you should treat it as such. Not by storing it al in files, but by properly constructing your SQL statements.

As others have mentioned, using prepared statements, or a library which which simulates them, is the way to go, e.g.

$db->Execute("insert into foo(x,y,z) values (?,?,?)", array($one, $two, $three));