日志注入（也稱日志文件注入）
很多應用都維護著一系列面向授權用戶、通過 HTML 界面展示的日志，因而成為了攻擊者的首要目標，這些攻擊者試圖偽裝其他攻擊、誤導日志讀者，甚至對閱讀和分析日志監測應用的用戶安裝后續攻擊程序。
日志的脆弱性取決于對日志編寫過程的控制，以及是否確保對日志條目進行任何監控或分析時，日志數據被看作非置信數據源。
簡單的日志系統可能使用file_put_contents()函數向文件中寫入文本行。比如，程序員可能采用以下格式的字符串來記錄登錄失敗的情形：
sprintf("Failed login attempt by %s", $username);
那么萬一攻擊者使用諸如“AdminnSuccessful login by Adminn”形式的用戶名呢？
如果把來自非置信輸入的該字符串插入日志中，攻擊者就能順利將其失敗登錄偽裝為管理員用戶無辜的失敗登錄。如再成功添加一次重試，數據的可信度甚至會更高。
當然，重點在于攻擊者可以添加各種日志條目，還可注入XSS矢量，甚至還能注入字符，擾亂日志條目在控制臺的顯示。
日志注入的目的
注入的目標也可能為日志格式解釋程序。如果分析器工具使用正則表達式解析日志條目，將其分解成數據字段，那么，注入的字符串可以通過精心構造以確保正則表達式與注入的多余字段相匹配，而非正確字段。例如，以下條目便可能造成問題：
$username = "iamnothacker! at Mon Jan 01 00:00:00 +1000 2009"; sprintf("Failed login attempt by $s at $s", $username, )
更過分的使用日志注入的攻擊者可能試圖建立目錄遍歷攻擊，使日志出現在瀏覽器中。正常情況下，向日志消息中注入PHP代碼并在瀏覽器中打開日志文件便可成功進行代碼注入，攻擊者可用精心設計并隨意執行這類代碼注入。這一點無需多講。如果攻擊者能在服務器上執行PHP，那么問題就大了，此時你的系統最好有足夠的深度防御來將損害降至最低。
防御日志注入
最簡單的日志注入防御方法是利用受認可的字符白名單對所有出站日志消息進行清理。比如，我們可以將所有日志限制為字母數字字符和空格。不屬于該字符列表的消息可能被認定為有害消息，進而出現有關潛在本地包含漏洞(LFI)的日志消息，以便告知你攻擊者可能進行的嘗試。這種方法很簡單，適用于簡單文本日志，此類日志消息無法避免非置信輸入的出現。
第二種防御則是將非置信輸入部分編碼為類似base64的編碼，其中保存著數量有限的認可的字符描述，同時還可在文本中存儲大量信息。
路徑遍歷（也稱目錄遍歷）
路徑遍歷（也稱目錄遍歷）攻擊通過讀取或寫入 web 應用的文件而試圖影響后端操作，其方法為注入能控制后端操作所采用文件路徑的參數。照此，通過推進信息披露以及本地/遠程文件注入，這類攻擊可以順利取得成功。
我們將分別對這類后續攻擊進行闡述，但路徑遍歷是使這些攻擊達成的根本漏洞之一。盡管以下功能特定于操縱文件路徑這一概念，但值得一提的是，許多PHP函數都不僅僅接受單純的文件路徑。譬如，PHP中的include()或file() 等函數能接受URI。這似乎很違反常理，但這使得以下兩種采用絕對文件路徑（即不依靠相關文件路徑的自動加載）的函數調用方法帶來相同的效果。
include(‘/var/www/vendor/library/Class.php’); include(‘file:///var/www/vendor/library/Class.php‘);
關鍵在于，在相關路徑處理的同時（php.ini和可用自動加載器的 include_path 設定 ），類似的PHP函數在各種形式的參數操縱下顯得尤其脆弱，其中包括文件URI 方案替換——一旦文件路徑初始處注入了非置信數據，攻擊者便可注入HTTP或 FTP URI。后面我們將在遠程文件包含攻擊中對這一點進行進一步闡述，現在繼續探討文件系統路徑遍歷的問題。
路徑遍歷缺陷的各種情況有一個共同特點，即文件路徑因受操縱而指向不同的文件。這一點通常通過向參數注入一系列 ../ （點-點-斜線）序列來實現，上述參數被整個添加或插入到 include()、require()、file_get_contents()等函數，甚至在有的人看來不那么可疑的函數中，比如DOMDocument::load()。
點-點-斜線序列允許攻擊者使系統導航或回溯至父目錄。因此像/var/www/public/../vendor 這樣的路徑實際上會指向/var/www/public/vendor。/public 后的點-點-斜線序列會回溯到該目錄的父目錄，也就是/var/www。從該簡單示例可以看出，利用這一方法，攻擊者便可讀取通過網站服務器可訪問的/public 目錄以外的文件。
當然，路徑遍歷不僅僅用于回溯。攻擊者也可注入新的路徑元素，從而訪問無法通過瀏覽器訪問的子目錄，無法訪問的原因可能為子目錄或其父目錄之一中的.htaccess中的deny from all 指令。PHP的文件系統操作不考慮Apache或其他網站服務商是如何配置并控制非公共文件和目錄的入口的。
路徑遍歷示例
防御路徑遍歷估計
本文系 OneAPM 工程師編譯整理。OneAPM 是應用性能管理領域的新興領軍企業，能幫助企業用戶和開發者輕松實現：緩慢的程序代碼和 SQL 語句的實時抓取。想閱讀更多技術文章，請訪問 OneAPM 官方博客。
本文轉自 OneAPM 官方博客
