Is “filter input, escape output” still valid with PDO

浪尽此生 提交于 2019-11-29 03:57:11

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)...

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.

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.

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.

rook

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!