评估在查询字符串中暴露行标识的安全风险

Question

公开SQL行的ID号是否存在安全风险？

例如，有一个ID为12的事件。

如果有人通过http://example.com/events/12访问它，或者有人向http://example.com/events/12发布POST以更新该记录（假设我当然允许这样做），这是一个安全问题吗？

Answer 1

向用户公开ID的问题通常在Web安全上下文中称为“不安全的直接对象引用”。

来自OWASP：

防止不安全的直接对象引用需要选择保护每个用户可访问对象的方法（例如，对象编号，文件名）：

1. 使用每个用户或会话间接对象引用。这可以防止 攻击者直接针对未经授权的资源。对于 下拉列表，而不是使用资源的数据库密钥 授权给当前用户的六个资源列表可以使用 数字1到6表示用户选择的值。该 应用程序必须将每用户间接引用映射回 服务器上的实际数据库密钥。 OWASP的ESAPI包括两者 开发人员可以使用的顺序和随机访问参考映射 消除直接对象引用。
2. 检查访问权限。每次使用直接对象引用 不受信任的来源必须包含访问控制检查以确保 用户已获得所请求对象的授权。

深度防御方法是同时进行1＆amp; 2。

Answer 2

是否显示，无所谓。

重要的是，您检查调用者是否已通过身份验证并且有权执行所请求的操作。

有人可能会向http://example/events/x吐出请求，其中x是递增数字。也许这是一个试图查看http://payroll/employee/x的史努比员工。

对用户进行身份验证，以确保他们是他们所说的人。表单身份验证，LDAP，你有什么。

确保用户有权在调用时执行每个操作。通常，用户属于有权更新老板工资，创建货件或取消信用卡的组。

如果您实施上述措施，id的来源无关紧要，无论是在cookie，隐藏表单元素，查询字符串，会话变量等等。

Answer 3

当您使用整数标识符时，URL和查询字符串特别不安全。毕竟，如果有一个12，几乎可以肯定是11或10. GUID使得更难猜测另一个项目，但仍然不应该被认为是安全的IMJO。

结论：您需要某种身份验证机制来确保用户是他声称的用户，以及授权机制以确保他能够看到您要向他展示的内容。