tags:

views:

143

answers:

5

Okay I was wondering when should I sanitize my code, when I add store it in the database or when I have it displayed on my web page or both?

I ask this question because I sanitize my code before it gets stored in the database but I never sanitize when its displayed for the user.

Here is an example of how I sanitize my code before its stored in the database.

$title = mysqli_real_escape_string($mysqli, $purifier->purify(strip_tags($_POST['title'])));
$content = mysqli_real_escape_string($mysqli, $purifier->purify($_POST['content']));
+1  A: 

There are distinct threats you are (probably) talking about here:

  • You need to sanitize data that's being inserted into the database to avoid SQL injections.
  • You also need to be careful with the data that's being displayed to the user, as it might contain malicious scripts (if it's been submitted by other users). See Wikipedia's entry for cross-site scripting (aka XSS)

What's harmful to your database is not necessarily harmful to the users (and vice versa). You have to take care of both threats accordingly.

In your example:

You probably want to use the purifier prior to data insertion - just ensure it's "purified" by the time the user gets it.

You might need to use striplashes() on data retrieved from the db to display it correctly to the user if magic_quotes are on

quantumSoup
So is that a yes to sanitize the code when its displayed?
meta
@meta read my edit
quantumSoup
There is never any need to run `stripslashes` on content retrieved from the database unless magic quotes is on. Further, meta is using the mysqli extension, not mysql, so that's the wrong method to call to escape data.
Charles
@Charles First of all, magic quotes are likely to be on. And oh, I didn't notice he was using mysqli. I am pretty sure he knows to put the "i" there, after "mysql" though. The function is a freaking allias to mysql_*. I'm just getting my point across, do we really need to get nitpicky? Geez
quantumSoup
It's not a nitpick if it's factually incorrect. Magic quotes are *not* likely to be on in any modern PHP installation. Please don't forget that you aren't just answering one person's question. Other people that are not the asker read what you've written, and you don't want them to learn the wrong thing as a result.
Charles
@Charles Guess I am behind the times, eh?
quantumSoup
+2  A: 

Rule is thumb is to sanitize ALL user input. Never trust the user.

Mike
+1  A: 

When you are putting something in the database, you make sure it's safe to put in the database.

When you are about to display something in a browser, you make sure it's safe to display it in the browser.

If you make something browser-safe before you put it in the database, then you are now picking up the habit of trusting that things will be browser-safe when they come out of the database. It's not a good habit to trust user data, even if you're pretty sure you cleaned it previously. Also makes it easy to forget to sanitize before output if you're using someone else's database or code.

Syntax Error
I would think that if you're code has database writing abstracted to a write function that always sanitizes them, then its safe to trust the data coming from the database?
chustar
If your code has that, then yes it would have safe output. But what if someone else changes the code in the future, or you get another source for your data? It's better to be sure that it's safe than have to trust that it's safe.
Syntax Error
A: 

I think you would want to escape the input (to avoid SQL injections) and sanitize (to avoid scripting attacks) at the same time, as you're inserting into the database.
This way, you only need to run the sanitizer once on insertion, rather than (potentially) millions of times on display.

chustar
A: 

You should always encode data when you display it. This way your application can do no wrong. This will protect you from bad data no matter how it came to be.

matt-dot-net
Just as long as you don't double-encode. It's safe to *strip on input* and *encode on output*.
Charles