Question

因此，为了保证安全，我们决定更改Parse Server的主密钥。

我们的iOS继续工作，因为它只需要应用程序ID，这是预期的，但令人惊讶的是我们的PHP脚本也保持运行，即使它们是使用WRONG MasterKey初始化的。

Parse PHP SDK是否完全忽略了主密钥更改？
我们怎么能阻止碰巧有应用程序密钥访问我们的Parse和“读取”数据的旧PHP脚本？

根据文件：

 ParseClient::initialize('YOUR_APP_ID', '', 'YOUR_MASTER_KEY');
 ParseClient::setServerURL('http://YOUR_PARSE_SERVER:1337/parse');

Answer 1

我对你的建议如下。

使用RestKey作为PHP作为您的第二个参数，然后IOS您可以使用clientKey作为您的第二个参数。

确保将restKey和clientKey添加到构造服务器端。

我的swift3例子也是如此！

 let configuration = ParseClientConfiguration {
            $0.applicationId = PARSE_APP_KEY
            $0.clientKey = PARSE_CLIENT_KEY
            $0.server = PARSE_URL
            $0.isLocalDatastoreEnabled = true

        }
        Parse.initialize(with: configuration)

编辑/报价：

如果您查看ParseClient::initialize，则主密钥存储在静态var $masterKey.中。ParseClient::_getRequestHeaders中使用此密钥（请求使用主密钥时）以提供X-Parse-Master-Key 1}}标头，主密钥为值。

主密钥肯定是使用的，但它取决于请求。如果$useMasterKey中的给定请求ParseClient::_request为false（默认值为false），则不会将主密钥添加到请求标头中。在这种情况下，不会使用主密钥，但这是预期的行为。

Answer 2

1。）是的，解析php sdk没有对主密钥进行任何验证。验证发生在您正在运行的Parse Server一侧。实质上，主密钥存在以允许覆盖sdk docs中提到的ACL。当发送请求使用主密钥的请求时，它将被提交给服务器。

基本上，如果您发出任何需要覆盖ACL的请求，并且您指示使用主密钥，那么将发送主密钥。在其他情况下，不会发送主密钥。您可以通过编写一些将发送主密钥的快速代码来测试这一点，例如$object->save(true)。在这种情况下，如果主密钥与服务器中加载的密钥不匹配，则将失败。

2。）你真的无法防止有人弄清楚你的App Id。您正在寻找的安全性并不像客户端那样在服务器端。您应该确保设置对象和类ACL，以限制对您不希望被任意个体读取（或写入）的所有对象（和类）的访问。角色是将其应用于广泛对象的一种相当好的方式，例如限制对Admin角色的访问。如果您锁定数据，则需要有人破坏现有帐户以访问该给定数据，而不是仅使用您的应用ID。

话虽如此，你应该总是警惕可能设法获取主密钥的人，因为这样可以绕过你设置的所有ACL（保持安全！）。

我希望这有助于澄清主人的角色。

解析PHP SDK完全忽略了MasterKey更改

2 个答案: