为啥在php中硬编码用户名密码安全威胁？

Posted 2023-03-28

【中文标题】为啥在php中硬编码用户名密码安全威胁？

【英文标题】：Why is hard coding username password security threat in php?为什么在php中硬编码用户名密码安全威胁？

【发布时间】：2021-01-13 19:51:17

【问题描述】：

我在 php 中有基本的登录系统。索引页面上的表单使用 POST 方法将用户名和密码提交到同一页面。用户名和密码是硬编码的。 这是处理索引页面上的 php 代码

if( isset ($_POST['submit']) ) 
$username='Admin';
$password='root';

  if(  ( $_POST['uname'] == $username ) && ( $_POST['pass'] == $password) ) 
         // Redirect to admin page
   
  else
       echo "Wrong credential";
 

我提到了This question，但无法理解为什么在这些情况下硬编码不好。

我的论点

这消除了 sql 注入的可能性 如果关闭错误报告，则永远不会看到源代码。

【问题讨论】：

硬编码凭据不是问题。问题是当你用纯文本对它们进行硬编码时。如果凭据是硬编码的，您仍然可以通过password_hash() 运行用户名/密码，并且只将结果（哈希）存储在文件中，然后使用password_verify() 验证它们。为什么你也可以对用户名进行哈希处理是因为你不需要在任何地方搜索用户名，而且它也可以防止爱管闲事的人。

一个参数：如果 php 处理程序配置错误，您可以看到源代码的纯文本。例如，这可能在 mod-apache 更新期间发生。

另一个论点：如果你使用 git 之类的版本控制软件，你会暴露凭据。

硬编码凭据不是问题，如果您将其存储在哈希上，但问题是您无法在不重新部署的情况下更改凭据，这太糟糕了

正如我所写的，我很确定如果 uname 和 pass 是布尔值 true，你可以打破它。由于 PHP 尝试将值转换为可比较的方式，字符串将变为布尔值 true。像这样的简单错误将允许某人轻松绕过身份验证。

【参考方案1】：

由于您没有使用数据库，这并不能消除 sql 注入的可能性。 您应该将用户名和密码存储在数据库中，将这些想法存储为一些散列算法，例如 SHA1，并应用“黄金规则过滤输入和转义输出”。

【参考方案2】：

硬编码不是安全威胁。这是一个不好的做法。 @tobias 评论 uname 或 pass 是布尔值也无害。所有输入在 php 中都被视为字符串