介紹
我問這個問題是因為我在這個主題上的所有發現都有關于變數$filename值風險的答案(我已經理解并知道安全使用的字串處理要求)。我還發現了一個關于API 安全使用的問題,但它以 OP 要求他的代碼的 cURL 版本結束。
我想知道fread(),file()和 file_get_contents()函式在通過具有外部參考的流與第三方網站互動時本身是否安全$filename(即外部鏈接,https://www.example.com而不是內部檔案路徑,如includes/my-file.php)。
例子
以下簡單應用程式的服務器安全問題是什么,該應用程式打開給定站點內容,將其所有源代碼“foobar”替換為“barbaz”并將其列印給用戶?
// User given URL.
$user_url = $_POST['url'] ?? null;
// Conditional content.
if (is_string($user_url) && preg_match('/^https?:\/\/. $/', $user_url)) {
// Print content with replacements.
print_r(str_replace("foobar", "barbaz", file_get_contents($user_url)));
} else {
// Warning.
if (is_string($user_url)) echo '<p>' . "You inserted an invalid URL :(" . '</p>';
// Form.
echo '<form method="post" action="">' .
'<label for="url-field">Your URL:</label>' .
'<input id="url-field" name="url" type="text">' .
'<button type="submit">Do it!</button>';
'</form>';
}
同樣,我知道這preg_match('/^https?:\/\/. $/', $user_url)是一個過于簡化的過濾器,并且應該分析給定字串的其他特征(例如長度)。
更多細節
我的目標是了解 PHP 用于獲取file_get_contents()、file()或fread()內容的程式是否存在任何已知的漏洞,所咨詢的第三方站點可以利用這些漏洞并對應用程式服務器構成風險。
我不關心回傳的字串,因為帶有惡意 JS 的源代碼不會是服務器端問題,而且我不會eval(file_get_contents($url))在我的代碼中撰寫類似的東西。
此外,確認客戶端 HTTP 請求資料(到我的應用程式)或 cookie 都不會發送到第三方網站(除非通過自定義背景關系明確完成)是否正確?
我對這些功能的困惑部分是由于處理內部服務器檔案路徑和外部參考之間的方法差異。雖然第一個讓他們打開檔案并讀取其中的行,但第二個需要互聯網協議(我還是有點缺乏經驗)來獲取函式的回傳內容。
uj5u.com熱心網友回復:
大多數(也許是所有)基于 PHP 檔案的操作都是通過流完成的,并且每個流包裝器(檔案、http、ftp 等)都有自己的代碼和邏輯,這意味著每個都可能存在潛在的安全漏洞。
可以在源代碼中找到默認的流包裝器及其相應的處理程式,這里也對實作者進行了深入了解。
您也可以手動注冊自己的流包裝器。事實上,您也可以取消注冊現有的包裝器,可能是核心包裝器(我沒有嘗試過),因此您或其他人也可以在理論上注入易受攻擊的代碼。
據我所知,在當前維護的 PHP 版本中,沒有公開宣布的與這些包裝器相關的未修補漏洞。這并不是說過去沒有,也不是說我知道任何未公開的。
對于您的第二個問題,不,當 Web 瀏覽器訪問file_get_contents針對 HTTP/HTTP 流使用的 PHP 頁面時,瀏覽器的初始請求(標頭等)中的任何內容都不會添加到流的請求中。該部分稱為“流背景關系”。可以在每個包裝器的源代碼中手動檢查未指定背景關系的默認值。尋找類似的代碼context && (tmpzval = php_stream_context_get_option,然后找到對應的else.
轉載請註明出處,本文鏈接:https://www.uj5u.com/caozuo/471168.html
