filter_input和mysqli_real_escape_string用于整数 [英] filter_input and mysqli_real_escape_string for integers

问题描述

我正在开发一个供内部使用的简单PHP数据库应用程序，但希望将其编码为最佳实践.我的某些页面正在接收来自GET请求的整数值，而我只是想知道真正需要多少验证和卫生条件.

I'm developing a simple PHP database application for internal use but would like to code it to best practices. Some of my pages are receiving integer values from GET requests and I'm just wondering how much validation and sanitation is really required.

当前，我正在使用具有指定最小值和最大值的$num = filter_input(INPUT_GET, 'num', FILTER_VALIDATE_INT, $num_options);.如果$num == false

Currently I'm using $num = filter_input(INPUT_GET, 'num', FILTER_VALIDATE_INT, $num_options); with specified min and max values. From here I'm exiting with an error message if $num == false

是否也需要使用$mysqli->real_escape_string($num);

目前，我不打扰，因为我认为使用整数进行SQL注入非常困难...

Currently I am not bothering because I think it's quite hard to do SQL injection using an integer...

谢谢

凯文

更新:要澄清我正在执行的查询，就像这样

UPDATE: To clarify the query I'm doing looks like this

$sql = "SELECT employeeID, concat(FirstName, ' ', LastName) as Name FROM employee WHERE employeeID='$num'";

推荐答案

与许多其他PHP用户一样，您在逃避错误也是错误的.您将其视为某种魔术棒，使某些邪恶角色"成为安全".
这是错误的主意.
尽管准备好的语句可以被视为一种魔杖，但转义并不是"SQL注入保护"的同义词.这只是一个字符串语法规则-不多也不少.

Like many other PHP users you are taking escaping wrong. You taking it as a some sort of magic wand which makes some "evil characters" "safe".
This is wrong idea.
though prepared statements can be taken as a sort of such a magic wand, escaping is not a synonym for "SQL injection protection". It is a merely string syntax rule - no more, no less.

是否还需要使用$ mysqli-> real_escape_string($ num);

Is it necessary to also use $mysqli->real_escape_string($num);

这是无关紧要的问题.
要逃避或不逃避决策，必须绑定到SQL，而不是数据源或任何验证:

It is irrelevant question.
To escape or not to escape decision have to be bound to SQL, not to the data source or any validations:

• real_escape_string()必须用于 sql字符串，即查询中用引号引起来的部分.尽管有任何先前的操作，但必须无条件使用.
• 对于查询的任何其他部分real_escape_string() 完全没有用.

• real_escape_string() have to be used for the sql strings, i.e. parts of the query enclosed in quotes. Have to be used unconditionally, despite of whatever previous manipulations.
• For the any other part of the query real_escape_string() being completely useless.

说明:
数据验证规则可以更改.
虽然SQL构建规则必须明确且无条件. 要使开发人员永远不要问自己这样的问题.
实际上，这是完全不同的事情:数据验证和查询构建.为什么要记住这些细节并相应地构建查询?为什么不基于完全与数据性质无关的一组通用规则构建查询?

An explanation:
Data validation rules can be changed.
While SQL building rules have to be explicit and unconditional. To make a developer never ask himself a question like this.
In fact, it's completely different matters: data validation and query building. Why keep in mind such details and build the query accordingly? Why not to build the query based on some set of general purpose rules, irrelevant of the data nature at all?

因此，再次提您的问题:

So, to your question again:

• 如果按原样将数据添加到查询中(不带引号)，则real_escape_string()在这种情况下将完全无用，但是强制转换/验证必不可少.
• 如果使用准备好的语句将数据添加到查询中，则real_escape_string()将完全无用甚至有害.
• 如果您要将数据添加到引号中-在这种情况下，您应该执行real_escape_string().
• 还值得一提的是，如果您将数据作为SQL语言的一部分添加到查询中-作为标识符或SQL关键字-real_escape_string()以及准备好的语句也完全没有用.白名单是您唯一的朋友

• if you are adding your data to the query as is, without quotes, real_escape_string() going to be completely useless in this case, but casting/validation become essential.
• if you are adding your data to the query using prepared statement, real_escape_string() going to be completely useless and even harmful.
• if you are adding your data to the query in quotes - you ought to do real_escape_string() in this case.
• it is also worth to mention that if you are adding your data to the query as a part of SQL language - as an identifier or an SQL keyword - real_escape_string() is completely useless too, as well as prepared statement. Whitelisting is your only friend here

这篇关于filter_input和mysqli_real_escape_string用于整数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！