Path Manipulation 路径操作

Abstract:

 

攻击者可以控制 AttachmentController.java 中第 205 行的 File() 文件系统路径参数，借此访问或修改其他受保护的文件。

 

 

Explanation:

 

当满足以下两个条件时，就会产生 path manipulation 错误：

 

1. 攻击者可以指定某一文件系统操作中所使用的路径。

 

2. 攻击者可以通过指定特定资源来获取某种权限，而这种权限在一般情况下是不可能获得的。

 

例如，在某一程序中，攻击者可以获得特定的权限，以重写指定的文件或是在其控制的配置环境下运行程序。

 

在这种情况下，攻击者可以指定通过 AttachmentController.java 中第 155 行的 getParameter() 进入程序的值，这一数值可以通过 AttachmentController.java 中第 205 行的 File() 访问文件系统资源。

 

 

例 1： 下面的代码使用来自于 HTTP 请求的输入来创建一个文件名。程序员没有考虑到攻击者可能使用像“../../tomcat/conf/server.xml”一样的文件名，从而导致应用程序删除它自己的配置文件。

 

 

String rName = request.getParameter("reportName");

File rFile = new File("/usr/local/apfr/reports/" + rName);

...

rFile.delete();

 

 

例 2： 下面的代码使用来自于配置文件的输入来决定打开哪个文件，并返回给用户。如果程序在一定的权限下运行，且恶意用户能够篡改配置文件，那么他们可以通过程序读取系统中以 .txt 扩展名结尾的所有文件。

 

 

fis = new FileInputStream(cfg.getProperty("sub")+".txt");

amt = fis.read(arr);

out.println(arr);

 

 

有些人认为在移动世界中，典型的漏洞（如 path manipulation）是无意义的 -- 为什么用户要攻击自己？但是，谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高，它们会强制扩展移动应用程序的攻击面（包括跨进程通信）。

 

例 3：以下代码将例 1 改编为适用于 Android 平台。

 

 

...

        String rName = this.getIntent().getExtras().getString("reportName");         File rFile = getBaseContext().getFileStreamPath(rName);

...

        rFile.delete();

...

 

 

 

 

Instance ID: 4EA59B14A6FC04D779BE37727BD5543F

 

Priority Metadata Values:

 

            IMPACT: 3.0

 

            LIKELIHOOD: 3.2

 

Legacy Priority Metadata Values:

 

            SEVERITY: 3.0

 

            CONFIDENCE: 5.0

 

 

Remediation Effort: 3.0

 

---

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

Recommendations:

 

防止 path manipulation 的最佳方法是采用一些间接手段：例如创建一份合法资源名的列表，并且规定用户只能选择其中的文件名。通过这种方法，用户就不能直接由自己来指定资源的名称了。

 

但在某些情况下，这种方法并不可行，因为这样一份合法资源名的列表过于庞大、难以跟踪。因此，程序员通常在这种情况下采用黑名单的办法。在输入之前，黑名单会有选择地拒绝或避免潜在的危险字符。但是，任何这样一份黑名单都不可能是完整的，而且将随着时间的推移而过时。更好的方法是创建一份白名单，允许其中的字符出现在资源名称中，且只接受完全由这些被认可的字符组成的输入。

 

 

Tips:

 

1. 如果程序正在执行输入验证，那么您就应确信此验证正确无误，并使用 HPE Security Fortify Custom Rules Editor（HPE Security Fortify 自定义规则编辑器）为该验证例程创建清理规则。

 

2. 执行有效的黑名单是一件非常困难的事情。如果验证逻辑依赖于黑名单，那么有必要对这种逻辑进行质疑。鉴于不同类型的输入编码以及各种元字符集在不同的操作系统、数据库或其他资源中可能有不同的含义，确定随着需求的不断变化，黑名单能否方便、正确、完整地进行更新。

 

3. 许多现代 Web 框架都提供对用户输入执行验证的机制。其中包括 Struts 和 Spring MVC。为了突出显示未经验证的输入源，HPE Security Fortify 安全编码规则包会降低 HPE Security Fortify Static Code Analyzer（HPE Security Fortify 静态代码分析器）报告的问题被利用的可能性，并在使用框架验证机制时提供相应的依据，以动态重新调整问题优先级。我们将这种功能称之为上下文敏感排序。为了进一步帮助 HPE Security Fortify 用户执行审计过程，HPE Security Fortify 软件安全研究团队提供了数据验证项目模板，该模板会根据应用于输入源的验证机制，将问题分组到多个文件夹中。

 

 

 

References:

 

[1] G. Hoglund, G. McGraw, Exploiting Software, Addison-Wesley, 2004

 

[2] FIO00-J. Do not operate on files in shared directories, CERT, https://www.securecoding.cert.org/confluence/display/java/FIO00-J.+Do+not+operate+on+files+in+shared+directories

 

[3] INPUT-1: Validate inputs, Oracle, http://www.oracle.com/technetwork/java/seccodeguide-139067.html#5

 

[4] Standards Mapping - Common Weakness Enumeration, CWE ID 22, CWE ID 73

 

[5] Standards Mapping - FIPS200, SI

 

[6] Standards Mapping - NIST Special Publication 800-53 Revision 4, SI-10 Information Input Validation (P1)

 

[7] Standards Mapping - OWASP Mobile Top 10 Risks 2014, M8 Security Decisions Via Untrusted Inputs

 

[8] Standards Mapping - OWASP Top 10 2004, A1 Unvalidated Input

 

[9] Standards Mapping - OWASP Top 10 2007, A4 Insecure Direct Object Reference

 

[10] Standards Mapping - OWASP Top 10 2010, A4 Insecure Direct Object References

 

[11] Standards Mapping - OWASP Top 10 2013, A4 Insecure Direct Object References

 

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1, Requirement 6.5.1

 

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2, Requirement 6.3.1.1, Requirement 6.5.4

 

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0, Requirement 6.5.8

 

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0, Requirement 6.5.8

 

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1, Requirement 6.5.8

 

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2, Requirement 6.5.8

 

[18] Standards Mapping - SANS Top 25 2009, Risky Resource Management - CWE ID 426

 

[19] Standards Mapping - SANS Top 25 2010, Risky Resource Management - CWE ID 022

 

[20] Standards Mapping - SANS Top 25 2011, Risky Resource Management - CWE ID 022

 

[21] Standards Mapping - Security Technical Implementation Guide Version 3.1, APP3510 CAT I, APP3600 CAT II

 

[22] Standards Mapping - Security Technical Implementation Guide Version 3.10, APP3510 CAT I, APP3600 CAT II

 

[23] Standards Mapping - Security Technical Implementation Guide Version 3.4, APP3510 CAT I, APP3600 CAT II

 

[24] Standards Mapping - Security Technical Implementation Guide Version 3.5, APP3510 CAT I, APP3600 CAT II

 

[25] Standards Mapping - Security Technical Implementation Guide Version 3.6, APP3510 CAT I, APP3600 CAT II

 

[26] Standards Mapping - Security Technical Implementation Guide Version 3.7, APP3510 CAT I, APP3600 CAT II

 

[27] Standards Mapping - Security Technical Implementation Guide Version 3.9, APP3510 CAT I, APP3600 CAT II

 

[28] Standards Mapping - Security Technical Implementation Guide Version 4.1, APSC-DV-002560 CAT I

 

[29] Standards Mapping - Web Application Security Consortium 24 + 2, Path Traversal

 

[30] Standards Mapping - Web Application Security Consortium Version 2.00, Path Traversal (WASC-33)