评估在查询字符串中暴露行身份的安全风险
暴露 SQL 行的 ID 号是否存在安全风险？
例如，有一个 ID 为 12 的事件。
如果有人通过 http://example.com/events/12 访问它，或者有人向 发送 POST，是否存在安全问题>http://example.com/events/12 为了更新该记录（当然假设我允许这样做）？
Is it a security risk to expose the ID number of a SQL row?
For example, there is an event with an ID of 12.
Is it a security concern if someone accesses it via http://example.com/events/12, or someone makes a POST to http://example.com/events/12 in order to update that record (assuming I allow this of course)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 Web 安全上下文中，将 ID 暴露给用户的问题通常被称为“不安全的直接对象引用”。
来自 OWASP：
防止不安全的直接对象引用需要选择一种方法来保护每个对象用户可访问对象（例如，对象编号、文件名）：
攻击者直接针对未经授权的资源。为了
例如，不使用资源的数据库键，而是使用下拉菜单
为当前用户授权的六种资源列表可以使用
数字 1 到 6 指示用户选择的值。这
应用程序必须将每个用户的间接引用映射回
服务器上的实际数据库密钥。 OWASP 的 ESAPI 包括两者
开发人员可以使用的顺序和随机访问参考图
消除直接对象引用。
不受信任的来源必须包括访问控制检查以确保
用户被授权使用所请求的对象。
纵深防御方法是同时执行 1 和 2。 2.
The problem of exposing ID's to users is often referred to as "insecure direct object references" in a web security context.
From OWASP:
Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):
attackers from directly targeting unauthorized resources. For
example, instead of using the resource’s database key, a drop down
list of six resources authorized for the current user could use the
numbers 1 to 6 to indicate which value the user selected. The
application has to map the per-user indirect reference back to the
actual database key on the server. OWASP’s ESAPI includes both
sequential and random access reference maps that developers can use
to eliminate direct object references.
untrusted source must include an access control check to ensure the
user is authorized for the requested object.
A defense in depth approach would be to do both 1 & 2.
显示或不显示都没关系。
重要的是您检查调用者是否经过身份验证并有权执行所请求的操作。
有人可能有一个机器人向
http://example/events/x发出请求，其中 x 是一个递增的数字。也许是一个史努比员工试图查看http://payroll/employee/x。对用户进行身份验证，以确保他们的真实身份。表单身份验证、LDAP，什么都有。
确保用户有权在调用时执行每个操作。通常，用户所属的组有权更新老板的工资、创建发货或取消信用卡。
如果您实施上述措施，则
id的来源并不重要，无论它是在 cookie、隐藏表单元素、查询字符串、会话变量等上。Whether to display or not, it doesn't matter.
What matters is that you check that the caller is authenticated and is authorized to perform the operation being requested.
Someone may have a bot spitting out requests to
http://example/events/xwhere x is an incrementing number. Perhaps it's a snoopy employee trying to viewhttp://payroll/employee/x.Authenticate the user to ensure that they are who they say they are. Forms authentication, LDAP, what have you.
Ensure the user has authorization to perform each action when called. Usually the user belongs to a group that has permission to update the boss' salary, create a shipment, or cancel a credit card.
If you implement measures as above, the source of the
idwon't matter, whether it's on the cookie, hidden form element, querystring, session variable, etc.当您使用整数标识符时，URL 和查询字符串尤其不安全。毕竟，如果有 12，几乎肯定会有 11 或 10。GUID 使猜测另一个项目变得更加困难，但仍然不应该被认为是安全的 IMJO。
底线：您需要某种身份验证机制来确保用户是他所声称的人，并需要授权机制来确保他可以看到您将要向他展示的内容。
URLs and querystrings are particularly insecure when you're using integer identifiers. After all, if there is a 12, there is almost certainly an 11 or a 10. GUIDs make it harder to guess another item, but still shouldn't be considered secure IMJO.
Bottom line: You need some sort of authentication mechanism to ensure that the user is who he claims to be, and authorization mechanism to ensure that he is allowed to see what you are about to show him.