|
|
因為這個原因，許多安全研究人員建議在php.ini配置中禁用指向allow_url_fopen。不幸的是，許多推薦這種方法的人，并沒有意識到，這樣會破壞很多的應(yīng)用并且并不能保證100%的解決remote URL includes以及他帶來的不安全性。
通常，用戶要求在他們使用其他的文件系統(tǒng)函數(shù)的時候，php允許禁止URL包含和請求聲明支持。
因為這個原因，計劃在php6中提供allow_url_include。在這些討論之后，這些特性在php5.2.0 中被backported。現(xiàn)在大多數(shù)的安全研究人員已經(jīng)改變了他們的建議，只建議人們禁止allow_url_include。
不幸的是，allow_url_fopen和allow_url_include并不是導(dǎo)致問題的原因。一方面來說在應(yīng)用中包含本地文件仍然是一件足夠危險的事情，因為攻擊者經(jīng)常通過sessiondata, fileupload, logfiles,...等方法獲取php代碼………
另一方面allow_url_fopen和allow_url_include只是保護了against URL handles標記為URL.這影響了http(s) and ftp(s)但是并沒有影響php或date(new in php5.2.0) urls.這些url形式，都可以非常簡單的進行php代碼注入。
Example 1: Use php://input to read the POST data
| ＜?php // Insecure Include // The following Include statement will // include and execute everything POSTed // to the server include "php://input"; ?＞ |
Example 2: Use data: to Include arbitrary code
| ＜?php // Insecure Include // The following Include statement will // include and execute the base64 encoded // payload. Here this is just phpinfo() include "data:;base64,PD9waHAgcGhwaW5mbygpOz8+"; ?＞ |
把這些放到我們的運算里面將會非常明顯的發(fā)現(xiàn)既不是url_allow_fopen也不是url_allor_include 被保障。這些只是因為過濾器很少對矢量進行過濾。能夠100%解決這個URL include vulnerabilities的方法是我們的Suhosin擴展.
php技術(shù)：php allow_url_include的應(yīng)用和解釋，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
