10.4

ch10.md

@@ -220,3 +220,35 @@ OWASP 拥有一些非常好的页面，关于身份校验和会话管理。我
 OWASP 拥有值得阅读的 XSS 预防速查表：
 
 +   https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet 
+
+## A4 避免直接引用不安全对象
+
+当应用允许攻击者（也是校验过的用户）仅仅修改请求中的，直接指向系统对象的参数值，来访问另一个未授权的对象时，就存在不安全对象的直接引用（IDOR）。我们已经在本地文件包含和目录遍历漏洞中看到了一些例子。
+
+根据 OWASP，IDOR 是 Web 应用中第四大关键漏洞。这些漏洞通常由不良的访问控制实现，或者“隐藏式安全”策略（如果用户不能看到它，他们就不能知道它的存在）导致。这些在没有经验的开发者之中是个常见的做法。
+
+这个秘籍中，我们会涉及在涉及访问控制机制时应该考虑的关键层面，以便预防 IDOR 漏洞。
+
+### 操作步骤
+
+1.  使用非直接引用优于直接引用。例如，不要通过参数中的名称来引用页面（`URL?page="restricted_page"`），而是要创建索引，并在内部处理它（`URL?page=2`）。
+
+2.  将非直接引用映射到用户（会话）层面，于是用户仅仅能够访问授权的对象，即使它们修改了下标。
+
+3.  在传递相应对象之前校验引用，如果请求的用户没有权限来访问，展示通用错误页面。
+
+4.  输入校验也是很重要的，尤其是目录遍历和文件包含的情况下。
+
+5.  永远不要采取“隐藏式安全”的策略。如果有些文件包含受限的信息，即使它没有引用，有些人也会把它翻出来。
+
+### 工作原理
+
+不安全对象的直接引用在 Web 应用中的表现形式有所不同，从目录遍历到敏感的 PDF 文档的引用。但是它们的大多数都依赖于一个假设，即用户永远不会找到方法来访问不能显式访问的东西。
+
+为了防止这种漏洞，需要在设计和开发期间执行一些积极操作。设计可靠授权机制，来验证尝试访问一些信息的用户的关键是，是否用户真正允许访问它。
+
+将引用对象映射为下标来避免对象名称直接用于参数值（就像 LFI 中的那样）是第一步。攻击者也可以修改下标，这很正常，就像对对象名称所做的那样。但是数据库中存在下标-对象的表的话，添加字段来规定访问所需的权限级别，比起没有任何表并且直接通过名称来访问资源，要容易得多。
+
+之前说过，下标的表可能包含访问对象所需的权限级别，更加严格的话还有拥有者的 ID。所以，它只能够在请求用户是拥有者的情况下访问。
+
+最后，输入校验必须存在于 Web 应用安全的每个层面。