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)