什么时候PHP代码真的应该被视为不安全的？

昨天我参加了PHP开发者职位的面试。我的工作是解决15道非常简单的测试题。其中一个问题是决定是否应该将类似于下面的代码视为不安全代码。我给出了一个错误的（事实证明）答案，而另一个人在那次采访中的论证相当令人惊讶（至少对我来说）

代码是这样的：

function someFunction($a)
{
    echo $a * 4;
}

someFunction($_GET['value']);

可能的答案是：

• 总是
• 仅当启用了

  register\u globals

  时
• 从来没有

正确答案得一分，对所选答案给出良好解释（论证）得第二分

我的回答是第三个：这个代码从来都不是不安全的。加上论证：因为，这只是一个简单的等式。这里没有文件或数据库操作，没有流、协议，什么都没有。这只是一个等式。没有别的了。无论攻击者试图执行的URL查询的格式有多么错误，都无法对PHP脚本执行任何错误操作。没有机会

我得了零分。我的回答既不正确，也不接受我的论点。正确的答案是：这段代码总是不安全的——您应该总是转义，从URL查询中得到的内容

我的问题是：这真的是一个好的观点吗？我们是否真的必须始终使用经验法则，即直接从查询中获取的任何内容都是不安全的，如果没有以任何其他方式进行过滤、转义或保护的话？这是否意味着，我教我的学生一种非安全的编码方法，因为在第一节PHP课上，他们编写了一个计算三角形面积的脚本，并且在他们的任务中使用了URL中未经扫描、未过滤的参数

我理解，安全和编写安全代码应该是最优先考虑的问题。但是，另一方面，这难道不是一点安全代码法西斯主义（如果我冒犯了某人，请原谅我）来威胁任何不安全的代码吗？即使没有人能够用它做任何伤害

---

或者也许我完全错了，而你可以对回响4次的函数造成一些伤害，你给了它什么？

问题是，以后有人可能会更改函数“somefunction”，而不仅仅是简单地将它乘以4

函数本身不是不安全的，但行：

 someFunction($_GET['value']);

这是完全不安全的。可能是

someFunction

被重构到另一个文件中，或者是在代码中。 您应该始终检查和清理用户提供的数据，以保护您自己和其他在某个库或函数上工作的人，而这些库或函数不是在不希望您向他们传递纯$\u GET数组数据的地方被捕获的

---

在与他人合作时尤其如此，这也是为什么在面试中会被问到的问题——看你是否展望未来的潜在问题，而不是看你是否明白当前的

someFunction

在传递可能危险的数据时是无害的。当您的同事重构某个函数以查询DB表时，这会成为一个问题。

由于没有花太多时间来处理您的代码示例，我不会说它可能被用来“造成伤害”，但是，除非传递某种形式的数字，否则您的函数将无法正常工作。从长远来看，最好避开代码，处理错误的数据，然后等待有一天，毫无戒心的用户将错误类型的值放入您的框中并将其破坏。

---

我敢肯定，你面试的公司只是在寻找一个有着确保代码完整、牢不可破的良好习惯的人。

永远不要相信来自用户的任何东西。别这样。即使您无法了解您的代码/类/包被误用的可能性，也要确保产品的输入完全符合您的预期，不要让人感到意外。最起码，有人可能会向该方法提供错误的输入，只是为了破坏你的应用程序，导致它显示错误，或者给你一个死亡的白色屏幕。执行基本乘法的代码是这种恶意的主要候选代码。它不仅适用于PHP，也适用于一般的编程/设计。

你在面试时正在工作？多么有趣。一个提示：如果面试官给出一个代码并询问是否不安全，如果存在一些get变量，总是说它不安全，即使它违背了您的逻辑。这取决于您对

$\u get

的实现。但这显然是一个骗人的问题。当呈现一个特定的实现时，您应该根据它的具体情况来判断，而不是一般化或假定的过时的服务器设置。所有的问题都是这样吗？@mario:不是！：]十五个人中只有四五个！但是，是的，面试后我有点头痛！：]+1.我同意通常执行输入验证，但不同意应该尝试预测或预测结果将用于的未来上下文，或者将来可能有人如何修改代码。@rambocoder作为一名专业人士，您应该预测未来常见的上下文，例如“代码可能会更改，所以不要假设用户数据是安全的”。虽然我大体上同意您的回答，但我也同意rambo coder的评论。这让我想起了一个想法，我的朋友有：你应该永远补充；即使在CSS中的最后一条规则中，因为有一天某人可能想添加一些东西，但可能没有看到；最后。让我们不要变得偏执。@trejder防范恶意用户数据是基础编程101，而不是过度偏执。这不是一个棘手的问题。Sarn，我不会投票否决你，因为你是一个新手，没有太多的观点，但是的，代码中的例子是危险的。