不安全的直接对象引用


当开发人员公开对内部实现对象(例如文件、目录或数据库密钥)的引用而没有任何验证机制(允许攻击者操纵这些引用来访问未经授权的数据)时,可能会发生直接对象引用。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

不安全的直接 obj 引用

例子

该应用程序在访问帐户信息的 SQL 调用中使用未经验证的数据。

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

攻击者修改浏览器中的查询参数以指向 Admin。

http://webapp.com/app/accountInfo?acct=admin

动手

步骤 1 - 登录 Webgoat 并导航至访问控制缺陷部分。目标是通过导航到 tomcat-users.xml 所在的路径来检索它。下面是该场景的快照。

1. 不安全的直接 obj ref1

步骤 2 - 文件的路径显示在“当前目录是”字段中 - C:\Users\userName$\.extract\webapps\WebGoat\lesson_plans\en,我们还知道 tomcat-users.xml 文件是保存在 C:\xampp\tomcat\conf 下

步骤 3 - 我们需要一直遍历当前目录并从 C:\ Drive 导航。我们可以通过使用 Burp Suite 拦截流量来执行相同的操作。

2 不安全的直接 obj 引用

步骤 4 - 如果尝试成功,则会显示 tomcat-users.xml 并显示消息“恭喜。您已成功完成本课程。”

2 不安全的直接 obj 引用

预防机制

开发人员可以使用以下资源/要点作为指南,以防止在开发阶段本身出现不安全的直接对象引用。

  • 开发人员应该仅使用一个用户或会话来进行间接对象引用。

  • 还建议在使用来自不受信任源的直接对象引用之前检查访问权限。