问题描述
|
我有另一位开发人员提出了将所有参数组合和加密/混淆到PHP页面的可能性，以此作为防止通过精心制作的url进行操作的安全措施，并防止数据库的内部知识（例如，了解数据库的ID）具体条目）。
换句话说，除了单个或多个公共查询参数（例如ID），还有一个加密的Blob，它将在服务器端解密，并在制作链接时重新加密。
这种方法有问题吗？有大量的优势值得吗？这种方法在野外使用效果良好吗？
解决方法
您应该设计系统以防止未经授权的访问。混淆（不可能对客户端生成的数据进行有用的加密）不是值得的防御措施。
相反，不是给用户一个数据库ID，而是给他们一个ID的哈希值（可能带有会话种子）。哈希的128位+搜索空间和（对于合理的DB大小）较低的冲突概率将是一种更好的方法。您还可以为服务器上的ID加密客户机不需要的值（使用种子），但要确保它具有与我提到的哈希值相同的属性，即与可能的值空间相比，搜索空间非常大。
,如果要防止用户弄乱GET参数，我建议您执行以下操作：
将隐藏的表单添加到所有页面。单击页面上的任意位置，会将一些数据填写到表单中，然后通过POST / SSL安全提交。沿着提交详细信息，传递您想要将用户定向到的URL。
在服务器端，收集参数，然后将其全局或在附加到目标URL的某种标识符下放入会话。发送回重定向。这样，如果用户刷新页面，他就不会对POST数据感到困惑。另外，如果他开始在应用程序中回退和盘旋，那么请杀死该会话缓存并将其发送到起始页。
我已经在一些在线银行软件中看到了这种技术。另一个好处是用户无法打开新窗口。
我认为它可以增加一定程度的安全性，但会严重改变开发方法并给您带来更多工作。我本人从未使用过这种方法，并且我认为只要有适当的ORM系统就可以安全地传递ID，在任何情况下，无论哪种类型，用户A都不会允许用户A访问数据开发人员将编写的代码数量。
,在某些情况下，这种类型的URL加密（或混淆）很有用。假设您在应用程序中建立了非常强大的安全性，并且所有主机都是安全无虞的。
现在，如果您的运营人员恰好是外部人员，并且您不希望他们通过即时更改日志级别来知道/看到这些敏感数据（ID），那么最好对它们进行加密，并按单个模块的要求对其进行解密。
通常，不应在URL参数中传递任何敏感数据，也应注意即使在更高级别也不要对其进行记录。