我最近將我的公司網站從託管公司（IIS）轉移到我們的內部服務器（Apache）。最初建立該網站的團隊做了一個糟糕的工作，整個事情都是一團糟遷移。雖然這一舉措相當順利，但查看error_log仍然有一些缺失的頁面。php fwrite中的安全漏洞？
而不是不斷地grep通過error_log「文件不存在」與此域相關的錯誤 - 我們有大約15左右，我們在這些服務器上承載 - 我想知道是否可能更容易做到簡單做當出現以下404錯誤：
當我鍵入這使我越來越不相信這一點是值得的事情。儘管潛在的問題是，使用fwrite是否存在潛在的安全問題？如果輸入要附加到文件中，是否需要進行任何類型的用戶輸入清理？這個輸入不會在任何值得的數據庫附近進行。提前致謝。
只要你是一個定義哪些文件，你正在編寫（而不是確定自該URL），應該不會有太大的風險：你會從用戶那裏得到的唯一的事情就是你要寫入文件的內容，如果你不執行該文件，但只是閱讀它，它應該是相當好的。
以這種方式記錄404錯誤的想法並不新鮮：我已經看到它完成了好幾次，並且從未遇到過任何主要問題（我看到的最大問題是一個文件變得很大，速度很快，因爲有太多的錯誤^^）
例如，Drupal做了這樣的事情：記錄404錯誤 - 但是對於數據庫，因此使用Web界面分析它們更容易。
那麼，只是通常的文件系統的東西：不要讓用戶指定文件將去的地方：像script.php?filename=../../../../../../../etc/passwd的東西甚至不應該有寫入/ etc/passwd的機會（腳本不應該有FS的權限）。 除此之外，fwrite（）沒有任何特殊字符允許它跳入某種命令模式。
另外，404頁（在httpd.conf）很簡單：
ErrorDocument 404 /error_page.php
，只是轉儲REQUEST_URL到文件
FWRITE應該是相當安全的。
或者，您可以使用一些通常列出未找到頁面的訪問日誌分析器。
如果它所做的只是寫入光盤，外部的唯一一個人就是讓它寫入光盤。很明顯，文件名不應該是一個通過無效url傳遞的參數。有些人可能會嘗試通過發送大量無效的頁面請求與真正長的URL進行利用。但是，如果有其他更有效的方法，那就是普通攻擊，但他們必須知道你正在做這件事，並且非常關心。
如果您將日誌編寫爲HTML（或其他允許嵌入代碼的文件類型），則需要注意的潛在問題是。這些文件當然容易受到XSS攻擊。
常見的日誌文件攻擊是請求包含嵌入的惡意JavaScript的URL。這些URL會直接寫入日誌文件，然後在任何人在Web瀏覽器中查看文件時執行。
您應該已經在您的error_log中記錄了404個錯誤。
通過一切手段使用自定義錯誤處理程序給用戶一個友好的錯誤消息，但如果此網站看到任何形式的嚴重吞吐量，然後從腳本使用fwrite不是一個好主意。爲了支持併發文件訪問，PHP本質上沒有一種複雜的文件鎖定語義 - 但是由於Web服務器正在爲您記錄信息，爲什麼要麻煩？
寫作很好。您的安全漏洞來自文件被查看，解釋或執行的時間。 – Cheekysoft 2009-12-23 16:15:20