PHP Fwrite中的安全漏洞？

Question

最近，我將公司網站從托管公司（IIS）遷移到了內部服務器（Apache）。 最初建造該站點的團隊做得很糟糕，整個遷移過程一團糟。 盡管移動進行得相當順利，但查看error_log仍然有一些缺少的頁面。

而不是必須不斷通過error_log來查找與該域相關的“文件不存在”錯誤-大約有15個左右的主機托管在這些服務器上-我想知道在404時簡單地執行以下操作是否會更容易發生錯誤：

• 重定向到php頁面並傳遞原始URL請求
• 讓新的php頁面將URL轉儲到日志文件

當我鍵入此內容時，我越來越不相信這是一項值得的工作。 盡管存在根本問題，但使用fwrite是否存在潛在的安全問題？ 如果要將用戶輸入追加到文件中，是否需要進行任何形式的清理？ 無論什么價值，此輸入都不會流到數據庫附近。 提前致謝。

Answer 1

只要您是定義要寫入哪個文件的人（而不是從URL確定） ，就不會有太大的風險：從用戶那里得到的唯一東西就是要寫入文件的內容，如果您不執行該文件，而只是閱讀它，那應該沒問題。

以這種方式記錄404錯誤的想法並不新鮮：我已經看過很多次了，並且從未遇到過任何重大問題（我看到的最大問題是文件變得非常快，因為存在錯誤太多^^）

例如，Drupal做到了這一點：記錄了404錯誤，但是記錄到了數據庫中，因此使用Web界面分析它們更加容易。

Answer 2

好吧，只是普通的文件系統之類的東西：不要讓用戶指定文件的存放位置： script.php?filename=../../../../../../../etc/passwd甚至都沒有機會寫入/ etc / passwd（腳本也不應該對此具有FS權限）。 除此之外，fwrite（）沒有任何特殊字符可以使它跳入某種命令模式。

另外，404頁面非常簡單（在httpd.conf中）：

ErrorDocument 404 /error_page.php

然后將REQUEST_URL轉儲到文件中

Answer 3

fwrite應該很安全。

另外，您可以使用一些訪問日志分析器，該分析器通常列出未找到的頁面。

Answer 4

如果它所做的只是寫到光盤上，那么外面唯一的人就是讓它寫到光盤上。 顯然，文件名不應是隨無效網址傳遞的參數。 有人可以通過發送大量帶有很長網址的無效頁面請求來嘗試利用它。 但是他們將必須知道您正在執行此操作，並且在還有其他更有效的方式（僅是一般攻擊）時會足夠小心。

Answer 5

如果您以HTML（或其他恰好允許嵌入代碼的文件類型）編寫日志，則可能要注意一個潛在的問題。 這些文件當然容易受到XSS攻擊。

Answer 6

常見的日志文件攻擊是請求包含嵌入式惡意JavaScript的URL。 這些URL直接寫入日志文件，當有人在Web瀏覽器中查看該文件時，該URL將執行。

1. 確保您寫入的文件不能被Web服務器用作HTML
2. 考慮對URL進行URL編碼或HTML編碼。

Answer 7

您應該已經在error_log中記錄了404錯誤。

一定要使用自定義錯誤處理程序為用戶提供更友好的錯誤消息，但是，如果此站點看到任何嚴重的吞吐量，那么從腳本中使用fwrite並不是一個好主意。 PHP本質上不具備支持並發文件訪問的復雜文件鎖定語義-但是既然Web服務器正在為您記錄信息，為什么要麻煩呢？