Ⅰ 如何查找php文件包含漏洞的方法

找360或安全聯盟檢測介面， 免費的。
主要是查上傳漏洞。可以網路下，夠學習一段時間的。

Ⅱ phpcms2008編輯器漏洞，發現FCKeditor編輯器，危害：可以通過FCKeditor的漏洞上傳惡意腳本。怎麼解決

可以更新使用最新版本的FCKeditor編輯器，您可以設置上傳類型，禁止上傳任何可執行的文件，如果你的網站是放在伺服器上面，可以安裝D盾等防護軟體，也可以使用最新的web網馬查殺。

Ⅲ 織夢提示media_add.php任意上傳漏洞怎麼辦

打開media_add.php搜索(大概在69行左右)：
$fullfilename = $cfg_basedir.$filename;

修改為：
if (preg_match('#\.(php|pl|cgi|asp|aspx|jsp|php5|php4|php3|shtm|shtml)[^a-zA-Z0-9]+$#i', trim($filename))) { ShowMsg("你指定的文件名被系統禁止！",'javascript:;'); exit(); } $fullfilename = $cfg_basedir.$filename;

這樣就把漏洞修復了

Ⅳ uploadsafe.inc.php 上傳漏洞 可以刪除嗎

上傳文件如果平常不用最好刪除，不然很容易直接被拿webshell

Ⅳ php文件上傳漏洞，請教這樣怎麼解決

檢查一下上傳文件的類型，不要根據後綴判斷類型。用Fileinfo函數去檢查他的真實類型。

示例：

$a=finfo_open(FILEINFO_MIME);
$b=finfo_file($a,'m.js');
print_r($b);//根據輸出的的mime類型進行進行判斷是不是你要求上傳的類型

還有個函數也能檢查文件的MIME類型:mime_content_type()

但是這個函數已經被廢棄，不推薦使用它

示例：

$a=mime_content_type('m.js');
print_r($a);//會輸出m.js文件的MIME類型

Ⅵ 如何實現php的安全最大化怎樣避免sql注入漏洞和xss跨站腳本攻擊漏洞

使用php安全模式

伺服器要做好管理，賬號許可權是否合理。

假定所有用戶的輸入都是「惡意」的，防止XSS攻擊，譬如：對用戶的輸入輸出做好必要的過濾

防止CSRF，表單設置隱藏域，post一個隨機字元串到後台，可以有效防止跨站請求偽造。

文件上傳，檢查是否做好效驗，要注意上傳文件存儲目錄許可權。

防禦SQL注入。

避免SQL注入漏洞

1.使用預編譯語句

2.使用安全的存儲過程

3.檢查輸入數據的數據類型

4.從資料庫自身的角度考慮，應該使用最小許可權原則，不可使用root或dbowner的身份連接資料庫。若多個應用使用同一個資料庫，也應該為資料庫分配不同的賬戶。web應用使用的資料庫賬戶，不應該有創建自定義函數，操作本地文件的許可權。

避免XSS跨站腳本攻擊

1.假定所有用戶輸入都是「邪惡」的

2.考慮周全的正則表達式

3.為cookie設置HttpOnly,防止cookie劫持

4.外部js不一定可靠

5.出去不必要的HTML注釋

6. 針對非法的HTML代碼包括單雙引號等，使用htmlspecialchars()函數。

Ⅶ 怎麼樣調用php圖片木馬

利用解析漏洞

一、IIS 5.x/6.0解析漏洞
IIS 6.0解析利用方法有兩種
1.目錄解析
/xx.asp/xx.jpg

2.文件解析
wooyun.asp;.jpg

第一種，在網站下建立文件夾的名字為 .asp、.asa 的文件夾，其目錄內的任何擴展名的文件都被IIS當作asp文件來解析並執行。

例如創建目錄 wooyun.asp，那麼
/wooyun.asp/1.jpg

將被當作asp文件來執行。假設黑闊可以控制上傳文件夾路徑,就可以不管你上傳後你的圖片改不改名都能拿shell了。
第二種，在IIS6.0下，分號後面的不被解析，也就是說
wooyun.asp;.jpg

會被伺服器看成是wooyun.asp還有IIS6.0 默認的可執行文件除了asp還包含這三種
/wooyun.asa
/wooyun.cer
/wooyun.cdx

二、IIS 7.0/IIS 7.5/ Nginx <8.03畸形解析漏洞
Nginx解析漏洞這個偉大的漏洞是我國安全組織80sec發現的…
在默認Fast-CGI開啟狀況下,黑闊上傳一個名字為wooyun.jpg，內容為
<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>

的文件，然後訪問wooyun.jpg/.php,在這個目錄下就會生成一句話木馬 shell.php

三、Nginx <8.03 空位元組代碼執行漏洞
影響版:0.5.,0.6., 0.7 <= 0.7.65, 0.8 <= 0.8.37
Nginx在圖片中嵌入PHP代碼然後通過訪問
xxx.jpg%00.php

來執行其中的代碼

四、Apache解析漏洞
Apache 是從右到左開始判斷解析,如果為不可識別解析,就再往左判斷.
比如 wooyun.php.owf.rar 「.owf」和」.rar」 這兩種後綴是apache不可識別解析,apache就會把wooyun.php.owf.rar解析成php.
如何判斷是不是合法的後綴就是這個漏洞的利用關鍵,測試時可以嘗試上傳一個wooyun.php.rara.jpg.png…（把你知道的常見後綴都寫上…）去測試是否是合法後綴

五、其他
在windows環境下，xx.jpg[空格] 或xx.jpg. 這兩類文件都是不允許存在的，若這樣命名，windows會默認除去空格或點,黑客可以通過抓包，在文件名後加一個空格或者點繞過黑名單.若上傳成功，空格和點都會被windows自動消除,這樣也可以getshell。
如果在Apache中.htaccess可被執行.且可被上傳.那可以嘗試在.htaccess中寫入:
<FilesMatch "wooyun.jpg"> SetHandler application/x-httpd-php </FilesMatch>

然後再上傳shell.jpg的木馬, 這樣shell.jpg就可解析為php文件

Ⅷ php漏洞與代碼審計過程中需要注意的幾點

1.xss + sql注入
其中佔大頭的自然是XSS與SQL注入，對於框架類型或者有公共文件的，建議在公共文件中統一做一次XSS和SQL注入的過濾。寫個過濾函數，可由如下所示：
$_REQUEST = filter_xss（$_REQUEST）；
$_GET = filter_xss（$_GET）；
$_POST = filter_xss（$_POST）；
$_COOKIE = filter_xss（$_COOKIE）；
$_POST = filter_sql（$_POST）；
$_GET = filter_sql（$_GET）；
$_COOKIE = filter_sql（$_COOKIE）；
$_REQUEST = filter_sql（$_REQUEST）；
這里有一點需要說明，$_REQUEST雖然等於$_GET+$_POST,但他們是獨立的數組，也就是說假設改變了$_GET的值，但$_REQUEST的值還是原來的值，所以過濾時都不能落下，至於其他的如$_FILE之類的就可忽略了。
最簡單的filter_xss函數是htmlspecialchars（）
最簡單的filter_sql函數是mysql_real_escape_string（）
當然，誰都知道這種過濾filter_sql只能過濾字元型和搜索型的注入，對於數字型是沒有辦法的，但也說明做了這層過濾後，只需在後面注意數字型的SQL語句就可以了，遇到了加intval過濾就可以了，這就變得容易多了。
2. 命令執行
對於命令執行，可以從關鍵字入手，總共可分為3類
（1） php代碼執行 :eval等
（2）shell命令執行：exec、passthru、system、shell_exec等
（3） 文件處理：fwrite、fopen、mkdir等
對於這幾類需要注意其參數是否用戶可控。
3.上傳漏洞
對於上傳漏洞，也是重點關注的地方，要仔細分析它的處理流程，針對上傳的繞過方式是很多的，最保險的方式：在保存文件是採用文件名隨機命名和後綴白名單方式。其次要注意的一點是上傳文件的地方可能不止一處，不要有遺漏，可能會碰到這樣的情況，突然在某個目錄裡麵包含了一個第三方的編輯器在裡面。
文件包含漏洞涉及的函數如include（） 、include_once（）、require（）、require_once（）、file_get_contents（）等
最常見的還是出在下載文件功能函數，例如download.php?file=///etc/passwd 這種類型中。
4. 許可權繞過
許可權繞過可分為兩類吧
（1）後台文件的未授權訪問。後台的文件沒有包含對session的驗證，就容易出現這樣的問題
（2）未作用戶隔離，例如mail.php?id=23顯示了你的信件，那麼換個ID, mail.php?id=24就查看到了別人的信件，編寫代碼是方便，把信件都存在一個數據表裡，id統一編號，前端展現時只需按id取出即可，但未作用戶隔離，判定歸屬，容易造成越權訪問。
這樣的例子是很常見的，給某銀行做評估是就經常發現這種漏洞。
5. 信息泄露
信息泄露算是比較低危的漏洞了，比如列目錄這種就屬於部署問題，而與代碼審計無關了，而像暴路徑、暴源碼這種是需要防止的。曾經遇到這樣的代碼
<?php if（empty（$_GET['a']）） {…} ?>
表面上似乎沒問題，可是當請求變為 xx.php?a[]=1時，即參數變為數組的時候，就會發生錯誤以致路徑泄露，而用isset判斷則不會，當然一個個防太麻煩，建議在配置文件中關閉錯誤提示，或者在公共文件中加入如下代碼以關閉錯誤顯示功能：
<?php error_reporting（0）；?>

Ⅸ centos PHP FastCGI 漏洞怎麼解決

漏洞描述：
Nginx默認是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通過正則匹配設置SCRIPT_FILENAME。當訪問http://192.168.1.102/phpinfo.jpg/1.php這個URL時，$fastcgi_script_name會被設置為「phpinfo.jpg/1.php」，然後構造成SCRIPT_FILENAME傳遞給PHP CGI。如果PHP中開啟了fix_pathinfo這個選項，PHP會認為SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就會將phpinfo.jpg作為PHP文件來解析了。
漏洞危害：
WebServer Fastcgi配置不當，會造成其他文件（例如css，js，jpg等靜態文件）被當成php腳本解析執行。當用戶將惡意腳本webshell改為靜態文件上傳到webserver傳遞給後端php解析執行後，會讓攻擊者獲得伺服器的操作許可權。
修復方案：
（Nginx用戶可以選擇方案一或方案二，IIS用戶請使用方案一）
方案一，修改php.ini文件，將cgi.fix_pathinfo的值設置為0。完成後請重啟PHP和NGINX（IIS）。
方案二，在Nginx配置文件中添加以下代碼：
代碼如下:

if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}