Question

由于Comcast的业务托管实施存在缺陷，我坚持使用PHP 5.4和单个数据库用户ID。 userid问题意味着在处理普通用户的请求时，还必须使用与我用于管理MySQL数据库的凭据相同的凭据。通过将ID的创建委托给一组受信任的用户，我可以控制谁可以以普通用户身份登录，这些用户将与最终用户交流他们登录应用程序所需的URL。而且，尽管服务器正在运行Apache，但它会忽略Authorization标头。

我认为某些黑客可能会破坏HostWays Unix服务器的文件系统保护并读取我的所有PHP源代码，因此我需要避免数据库凭据出现在PHP源代码的MySQL connect调用中。我已经提出了以下用于加密数据库凭据的方案，并且我想确保该方案实际上是有效的。

我将在配置文件中定义一个名为$ credentials的全局变量。我将使用以下代码在开发环境中产生价值：

$cipher = "AES-128-CBC";
$secretkey = …; // it's a secret!
$secret = openssl_encrypt("$dbuser:$dbpass", $cipher, $secretkey);

请记住，我坚持使用PHP 5.4，当我在crypto / decrypt调用中使用初始值时，无法克服openssl_decrypt中的神秘错误。无论如何，这些代码至少可以正常工作。

可以通过两种方式访问我的PHP应用程序：一种是通过来自C ++桌面应用程序的POST事务中的XML有效负载进行访问；另一种是通过GET中的普通URL。两种方法都将使用HTTPS。 XML模式要求提供$ secretkey的身份验证参数。

普通用户将通过浏览器使用GET事务的URL。它将包含secret =参数，该参数对用户的登录ID和$ secretkey进行编码。在将用户添加到授权用户列表的交易期间，我将生成secret =参数：

$cipher = "AES-128-CBC";
$key = "Fortune42Cookies!";
$secret = openssl_encrypt("$username:$secretkey", $cipher, $key);

在此代码中，$ secretkey是将该最终用户添加到列表中的受信任用户登录后剩下的。最终用户登录时使用的相应解密代码如下：

$cipher = "AES-128-CBC";
$key = "Fortune42Cookies!";
$clearsecret = explode(":", openssl_decrypt($secret, $cipher, $key));
$username = $clearsecret[0];
$secretkey = $clearsecret[1];
$this->db = new mydatabase($secretkey);
. . .
class mydatabase extends mysqli {
    public function __construct($secretkey) {
        public $credentials; // set by the configuration script
        $cipher = "AES-128-CBC";
        $cred = explode(":", openssl_decrypt($credentials, $cipher, $secretkey);
        parent::__construct(<database path>, $cred[0], $cred[1], <dbname>);
        }
    }

总而言之，__construct调用使用$凭据，该凭据以加密形式存储在我的假定的黑客可以读取的配置文件中。我们使用安全的XML数据包或URL中提供的$ secretkey解密它们，以进行安全的GET交易。

我在此方案中看到的一个缺陷是，一名黑客学习了注册用户的登录ID，并阅读了PHP源代码以学习愚蠢的Fortune42Cookies！键可以构造该用户的唯一$ secret，从而模拟该用户。因为数据库只有一组凭据，所以黑客将拥有前往城市的密钥。

不过，额外的保护层（黑客需要击败UNIX文件系统保护并了解真实最终用户的名称）似乎是值得的。

五十多年的软件开发经验告诉我，我错过了一些重要的事情。什么事？

我需要克服ISP的PHP环境的限制

0 个答案: