使用 PHP 进行代码注入
我知道如何防止 SQL 注入和攻击东西&正在验证用户输入...但想知道您是否正在从用户输入字段中获取数据&数据是一个字符串，此数据在代码中使用的安全性如何：
if ($i == $_POST['userinput']) {
....
}
以上只是一个示例，试图解决我的问题，询问您需要采取哪些步骤&在什么情况下。
显然它在上面的例子中不起作用，但只是试图阻止人们做类似 include('whatever.php'); 的事情。 ETC。
I'm aware of how to protect against SQL injections & stuff & validating user input... but was wondering if you are taking data from a user input field & the data is a string how safe is this data to use inside your code for stuff like:
if ($i == $_POST['userinput']) {
....
}
The above is just an example at trying to get across my question at asking what steps you need to take & in what circumstances.
Obviously it wouldn't work in the above instance, but just trying to prevent people doing something like an include('whatever.php'); etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
正如您所展示的，与变量进行比较本身并不危险，因此无需担心。
在 include 语句、数据库查询、文件名、
eval()调用、HTML 页面等中使用时，用户输入会变得潜在危险每一种用途都有一种正确的卫生方法。Making a comparison against a variable, like you show, is not dangerous in itself, so there's nothing to worry about there.
User input becomes potentially dangerous when used, in an include statement, in a database query, in a file name, in an
eval()call, in a HTML page, etc. every one of those uses has one correct sanitation method.与用户提供的变量相比很好，它们只是作为字符串处理。关于您的
include('whatever.php')示例，请使用白名单来防止它：comparing to user provided variables is fine, they are simply handled as string. regarding your
include('whatever.php')example, use whitelisting to protect against it:除非您从
create_function等字符串调用eval或类似的函数来创建并运行实际的 PHP 代码，否则您通常不需要担心关于实际的代码注入。正如您已经指出的，在直接根据用户输入执行包含或调用函数时，您确实需要小心。事实上您知道这一点意味着您可能已经在这方面做好了充分的准备。
Unless you are calling
evalor similar functions that create and run actual PHP code from a string likecreate_function, you generally don't need to worry about actual code injection.As you've already pointed out, you do need to be careful when performing includes or calling functions based directly on user input. The fact that you knew this means that you're probably already well-prepared in that regard.
来自用户的数据潜在是危险的，但这并不意味着它始终是危险的——这取决于您如何处理它。
虽然过滤/白名单/清理数据始终是良好的做法，但您必须做的绝对最低限度是避免直接使用它来执行与环境主动交互的操作：处理文件系统（包括、fopen、file_(get|put)_contents、等）、数据库、生成 HTML 输出等。
当然，不同的情况需要不同的措施：例如，在构建数据库查询时使用（正如我经常看到的）
htmlspecialchars()是没有意义的——该函数的目的是避免代码注入浏览器输出，因此应该使用它。简而言之，没有神奇的一句话答案，您必须知道什么是危险的以及何时危险，并采取相应的行动。
Data coming from users is potentially dangerous, but it doesn't mean it's dangerous always -- it depends on what you do with it.
While filtering/whitelisting/sanitizing data is always good practice, the absolute minimum you must do is avoid using it directly to do things that interact actively with the environment: dealing with the filesystem (includes, fopen, file_(get|put)_contents, etc.), the database, generating HTML output and so on.
Of course, different cases call for different measures: for example, there is no point in using (as I often see)
htmlspecialchars()when building database queries -- that function's purpouse is to avoid code injection in browser output, so it should be used for that.In short there is no magic one-sentence answer, you have to know what's dangerous and when, and act accordingly.
本身作为字符串就可以了。还是加斜杠比较安全，保证
'和"这样的符号不冲突。主要是对SQL数据库有危险。As a string by itself, it is fine.It is still safer to addslashes to ensure that symbols such as
'and"do not clash. It's mainly a danger to SQL Databases.