Are These Two Functions Overkill for Sanitization

Are these two functions overkill for sanitization?

It's true, but this level of escaping may not be appropriate in all cases. What if you want to store HTML in a database?

Best practice dictates that, rather than escaping on receiving values, you should escape them when you display them. This allows you to account for displaying both HTML from the database and non-HTML from the database, and it's really where this sort of code logically belongs, anyway.

Another advantage of sanitizing outgoing HTML is that a new attack vector may be discovered, in which case sanitizing incoming HTML won't do anything for values that are already in the database, while outgoing sanitization will apply retroactively without having to do anything special

Also, note that strip_tags in your first function will likely have no effect, if all of the < and > have become < and >.

Is it recommended to have a santizing function that combines two or more built in sanitizing functions in php?

each function serves its own purpose, you shouldn't use any function not for their intended use.

1. you should use mysql_real_escape_string before using the parameter in mysql query.
2. you should use htmlspecialchars before outputting to page.

that's about it.

A better SQL string sanitization function

There can never and will never be one function to sanitize everything. You must choose the right tool for the job.

1) htmlspecialchars($var,ENT_QUOTES) works well for most xss.

2) Parametrized query libraries like PDO and MySQLi work best for sql injection.

3) For CRLF injection, just remove new lines: str_replace("\n","",$var)

4) For Command injection use escapeshellarg()

And there are many other forms of injection.

Is sanitizing data + parameterisation in PDO oveekill?

There are three possible answers to this question.

1. If your concern is SQL injection only, and whole SQL query is hardcoded in PHP script (like in your example), then nothing but prepared statement is needed. And thus sanitize_string is overkill and rather irrelevant.
2. If your concern is SQL injection only, and some parts of SQL are assembled dynamically, you have to protect these parts. But protection should be specific for these parts, which makes sanitize_string rather useless.
3. If your concern is not only SQL injection but whatever else security or usability issues, then you may want to sanitize or validate your data according to these concerns. One of these cases might utilize sanitize_string as well.

mysql(i)_real_escape_string, safe to rely on?

A really great day today - second good attempt to create a sensible database abstraction layer in a row.

should I use mysqli_real_escape_string for sanitization?

Nope.
Just because this function doesn't sanitize anything.

But to format SQL string literals this function is a must and cannot be avoided or replaced.

So, you are using this function exactly the right way, formatting strings only and formatting them unconditionally.

So, you have you queries perfectly safe, as long as you can use a ? mark to substitute the actual data (and - to make even nitpick complains idle - as long as you set SQL encoding using mysql(i)_set_charset() function).

If someone calls your approach broken - just ask them for the complete snippet of proof-code to show the certain vulnerability.

However, let me draw your attention to a couple of important things.

1. Dynamic SQL query parts are not limited to strings only. For example, these 2 queries won't work with your function:

   SELECT * FROM table LIMIT ?,?
   SELECT * FROM table ORDER BY ?
   

   just because numbers and identifiers require different formatting.
   
   So, it's better to use type-hinted placeholders, to tell your function, which format to apply

2. To run a query is only a part of the job. You need to get results as well. Why not to get them already, without bloating your code with unnecessary calls?
3. There should be a way to insert literal ? marks into query without parsing them.

Please, take a look at my class, which built on the very same principle as yours but with improvements I mentioned above. I hope you will find it useful or at least worth to borrow an idea or two.

Should i sanitize $_POST data if used in if statement?

The short answer is no; for an if statement, your code is safe.

However, if you edit the code later, you should use prepared statements in you database queries.

Will these functions protect me from XSS and SQL injections?

A cross site scripting attack allows an attacker to execute code hosted on another server on your webpage. I would say that stripping the tags and running it through the purifier are a good start as long as you aren't whitelisting the that way an attacker can't link or embed code using inline JavaScript.

I would look at a good framework like CodeIgnitor which would handle much of the xss and sql injection automatically.

Remember that while it may seem like a lot of code, you should be able to write some type of function (or use an existing framework) that will make future projects faster to code and more secure.

To answer your question, it's a good start for xss but an attacker may still be able to insert an sql injection as the plugin you are using does not specifically mention anti-sql injection.

Is htmlentities() bullet proof?

You will need to explicitly specify proper encoding (e.g: utf-8), Chris had a post on how to inject code even calling htmlentities without appropriate encoding.

http://shiflett.org/blog/2005/dec/google-xss-example

---

Related Topics