Is “filter input, escape output” still valid with

问题:

I've read this before "filter input, escape output" but is filtering input really needed when I use PDO with PHP? I thought with PDO I don't need to filter input because the prepared statement takes care of sql injections. I think "escape output" is still valid, but is "filter input" still valid?

回答1:

Yes, it is still valid.

Filtering is not about preventing security vulnerabilities, it's about not populating your database with garbage. If you're expecting a date, make sure it at least looks like a date prior to storing it.

Escaping output is about preventing security vulnerabilities (namely XSS or Cross Site Scripting).

So yes, both are quite important and are totally unrelated to SQL Injection (although a fair number of developers still confuse filtering with escaping for SQL queries and hence can still be subject to vulnerabilities)...

回答2:

Depending on what the data you're saving is, yes it can still be valid.

For example, let's say you have a comment box and a user writes a message containing HTML markup. In this case you would often want to remove the said HTML markup from the comment text, even if it ended up being escaped (afterall, it probably won't look very nice).

There are other cases too, like if you have a phone number field, you might want to filter it so it's in the specific format your application uses and so on.

回答3:

Always filter user input. Always. Maybe you're protecting against attacks, or maybe you're performing business rule validation, etc. Keep in mind that there is no technology or procedure that will prevent all attacks, only attacks it was specifically designed to prevent. SQL injection isn't the only problem to avoid.

回答4:

As per sql-injection and security, if you're using PDO properly with bind variables, no you don't need to sanitize. But as Jani pointed out, depending on the data you are saving, such as a text field which doesn't allow html, you might want to sanitize your data, or if the field should be a number, running parseInt() on it or something. But this isn't going to be required to security, but for your own database sanity. It's kind of ugly when someone tries to put html in a comment and you spit it out and you see > < etc.

回答5:

Yes, it is escaping input, but not immediately like magic_quotes_gpc. Magic quotes is an awful approach to security. Vulnerabilities are highly dependent on how the tainted data is being used, you can never have 1 function that fixes everything all of the time. Also during the flow of the application there may be a case when another function undermines magic_quotes, such as stripslashes(), base64_decode(), urldecode(), htmlspecialchars_decode($var,ENT_QUOTES); and even substr().

In short, you must always escape input at the time of use. pdo and adodb does this, and it does it perfectly.