A. 應用存在任意文件讀取漏洞怎麼處理
初始化設置 END *///--------------------------------------------------require (ROOT_PATH . ADMIN_PATH . '/includes/config.php');define('CLS_PATH', ROOT_PATH . ADMIN_PATH . '/');include ROOT_PATH . ADMIN_PATH . '/includes/base/autoload.class.php';autoloader::init();/* 初始化memcached *///$cache = new base_memcached();
配置文件中自然有資料庫賬號，這個暫且不說。先看autoload.class.php。autoload實現自動載入類的功能。通過其實現方式拼接出存在漏洞的action類文件路徑。
/** * 固定路徑的class 類文件 以.class.php 結尾 */private function base_class($
B. 文件上傳漏洞有哪些挖掘思路
文件上傳漏洞作為獲取伺服器許可權最快的方式，雖然相關資料很多，但很多人對上傳校驗方式、如何針對性繞過檢測、哪種上傳和解析的場景會產生危害等還是比較模糊。本文作一些闡述，然後補充一些除了上傳webshell的其他非常規挖掘姿勢，包括XSS、重定向、Dos、CSRF等等。
1、基礎知識：
要深入了解文件上傳，必須了解上傳屬性、常見文件的結構、圖形處理函數等內容。
1） 報文特點：
觀察文件上傳報文的特點：
Header中Content-Type特徵有二：
1.multipart/form-data（form表單的enctype屬性，規定為二進制數據）
2.boundary字元串（作用為分隔符，以區分POST數據）
POST內容特徵有五：
1.Content-Disposition：form-data
2. name：input表單名
3.filename：文件名
4.Content-Type：定義文件的類型和網頁的編碼，決定瀏覽器將以什麼形式、什麼編碼讀取這個文件；
5.boundary：Content-Type的值前面加了兩個---
2） 常見校驗規則
現存常用的上傳校驗規則無非下面幾類：
1.客戶端javascript校驗（後綴名）
2.文件頭content-type欄位校驗（image/gif）：附帶參數
4.後綴名黑/白名單校驗：擴展名
5.文件內容頭校驗：GIF89a
6.文件內容校驗：文件信息，二次渲染
7.自定義正則校驗
3）一個澄清
文件上傳和文件解析是兩個過程，即使我們上傳的是php文件，但解析為圖片，訪問php文件會顯示「圖片無法顯示」；或者我們上傳的是jpg文件，但裡面混有shell腳本，若被解析為php文件也會執行；又或者上傳處沒法繞過檢測，只能上傳jpg文件，但在其他功能處存在文件包含等功能，仍可執行成功。
還是回到安全的本質，上傳是「輸入」，那文件解析就是「輸出」，任何漏洞挖掘都需要結合輸入+輸出。
2、繞過技巧：
這里匯總一些實戰中較常用的繞過技巧：
1）後綴名黑名單
以下替換後綴也可以解析為shell：
php：.phtml,.phpt,.php3,.php3p
asp：.aspx，asmx，ashx，web.config
perl:.pl,.pm,.cgi,.lib
jsp:.jspx,.jsw,.jsv,.jspf
Coldfusion:.cfm,.cfml,.cfc,.dbm
另外可以配合操作系統的文件命名規則：
.php.,.php空格，.php:1.jpg,.php::$DATA等
這些後綴的文件會被windows系統自動去掉不符合規則符號後面的內容，從而只留下.php。
2）後綴名白名單
除了結合各種伺服器解析特性，較常用的是Null Byte Injection空位元組注入，插入空位元組值的原因是某些應用程序伺服器腳本語言使用c/c++庫來檢查文件名和內容。在C/C ++中，一行以/00結尾或稱為NullByte。因此，只要解釋器在字元串的末尾看到一個空位元組，就會停止讀取，認為它已經到達字元串的末尾。
如，我們將要上傳的Happy.jpg的名稱更改為Happy.phpA.jpg，然後上傳文件，在Burp中捕獲請求，切換到Hex視圖。在字元串視圖中找到文件名。查看相應的Hex表，並將41（'A'）替換為00（為空位元組）。結果字元串變為Happy.php（空）.jpeg。由於php解釋器在內部使用C語言庫，它將停止讀取Happy.php後的文件名，文件將保存為Happy.php。
另一種繞過白名單的方法是使用雙後綴：shell.php.jpg。
C. 文件上傳漏洞如何搭建
文件上傳是Web應用中比較常見的功能，用戶經常會通過文件上傳的功能分享照片、修改頭像或上傳附件等操作；文件上傳漏洞是指用戶上傳了一個可執行的腳本文件，並通過此腳本文件獲得了執行服務端命令的能力；文件上傳本身是一個網站正常的業務需求，但如果文件在上傳之後，伺服器端沒有妥善的處理，就會導致嚴重的後果。簡單寫一個php上傳代碼演示php上傳漏洞。
1.首先搭建phpstudy的安裝環境，在phpstudy網站根目錄建立php演示文件夾，放入php文件上傳代碼。
2.php文件上傳漏洞演示代碼，代碼未限制任何文件屬性的上傳。
3.
寫一個phpinfo.php文件,通過瀏覽器訪問進行上傳。
4.
提示上傳成功，保存於uploads路徑中，可以猜想保存路徑為http://10.10.10.1/php/uploads
5.
嘗試訪問phpinfo.php文件使用剛才猜想的路徑，http://10.10.10.1/php/uploads/phpinfo.php,phpinfo函數被執行。
D. 文件上傳漏洞攻擊方法有什麼
文件上傳漏洞是什麼？怎樣防禦文件上傳漏洞攻擊？文件上傳漏洞是web安全中經常利用到的一種漏洞形式。這種類型的攻擊從大的類型上來說，是攻擊 數據與代碼分離原則 的一種攻擊。
一些web應用程序中允許上傳圖片，文本或者其他資源到指定的位置，文件上傳漏洞就是利用這些可以上傳的地方將惡意代碼植入到伺服器中，再通過url去訪問以執行代碼
造成文件上傳漏洞的原因是
對於上傳文件的後綴名（擴展名）沒有做較為嚴格的限制
對於上傳文件的MIMETYPE 沒有做檢查
許可權上沒有對於上傳的文件的文件許可權，（尤其是對於shebang類型的文件）
對於web server對於上傳文件或者指定目錄的行為沒有做限制
下面就閑話一些文件上傳漏洞的防禦方式和攻擊者的繞過方式
1.前端限制
function check(){
var filename=document.getElementById("file");
var str=filename.value.split(".");
var ext=str[str.length-1];
if(ext=='jpg'||ext=='png'||ext=='jpeg'||ext=='gif'){
return true;
}else{
alert("這不是圖片！")
return false;
}
return false;
}
在表單中使用onsumbit=check()調用js函數來檢查上傳文件的擴展名。這種限制實際上沒有任何用處，任何攻擊者都可以輕而易舉的破解。只能用於對於用戶完全信任的情況下，很難稱之為一種安全措施只能稱之是一種防止用戶誤操作上傳的措施，
反制：
隨便的編輯一下頁面/用burpsuite/寫個小腳本就可以突破之，無須多言
2.檢查擴展名
顧名思義，就是在文件被上傳到服務端的時候，對於文件名的擴展名進行檢查，如果不合法，則拒絕這次上傳
在這里，還有一點是值得一提的，在檢查擴展名是否合法的時候，有兩種策略
黑名單策略，文件擴展名在黑名單中的為不合法,示例代碼
$postfix = end(explode('.','$_POST['filename']);
if($postfix=='php'||$postfix=='asp'||$postfix=='sh'){
echo "invalid file type";
return;
}
白名單策略，文件擴展名不在白名單中的均為不合法
$postfix = end(explode('.','$_POST['filename']);
if($postfix=='jpg'||$postfix=='png'||$postfix=='gif'){
//save the file and do something next
} else {
echo "invalid file type";
return;
}
白名單策略是更加安全的，通過限制上傳類型為只有我們接受的類型，可以較好的保證安全，因為黑名單我們可以使用各種方法來進行注入和突破
反制
在一些 webserver 中，存在解析漏洞
1.老版本的IIS中的目錄解析漏洞，如果網站目錄中有一個 /.asp/目錄，那麼此目錄下面的一切內容都會被當作asp腳本來解析
2.老闆本的IIS中的分號漏洞：IIS在解析文件名的時候可能將分號後面的內容丟棄，那麼我們可以在上傳的時候給後面加入分號內容來避免黑名單過濾，如 a.asp;jpg
3.舊版Windows Server中存在空格和dot漏洞類似於 a.php. 和 a.php[空格] 這樣的文件名存儲後會被windows去掉點和空格，從而使得加上這兩個東西可以突破過濾，成功上傳，並且被當作php代碼來執行
4.nginx空位元組漏洞 xxx.jpg%00.php 這樣的文件名會被解析為php代碼運行
5.apache的解析漏洞，上傳如a.php.rar a.php.gif 類型的文件名，可以避免對於php文件的過濾機制，但是由於apache在解析文件名的時候是從右向左讀，如果遇到不能識別的擴展名則跳過，rar等擴展名是apache不能識別的，因此就會直接將類型識別為php，從而達到了注入php代碼的目的
3.檢查HTTP Header中的Content-Type
HTTP協議規定了上傳資源的時候在Header中加上一項文件的MIMETYPE，來識別文件類型，這個動作是由瀏覽器完成的，服務端可以檢查此類型不過這仍然是不安全的,因為HTTP header可以被發出者或者中間人任意的修改，不過加上一層防護也是可以有一定效果的
反制
使用各種各樣的工具（如burpsuite）強行篡改Header就可以，太容易將header中的
Content-Type: application/php
或者其他類型
改為
Content-Type: image/jpg
Content-Type: image/png
Content-Type: text/plain
等這些web程序允許的淚洗改附上常用的MIMETYPE表
text/plain（純文本）
text/html（HTML文檔）
text/javascript（js代碼）
application/xhtml+xml（XHTML文檔）
image/gif（GIF圖像）
image/jpeg（JPEG圖像）
image/png（PNG圖像）
video/mpeg（MPEG動畫）
application/octet-stream（二進制數據）
application/pdf（PDF文檔）
application/(編程語言) 該種語言的代碼
application/msword（Microsoft Word文件）
message/rfc822（RFC 822形式）
multipart/alternative（HTML郵件的HTML形式和純文本形式，相同內容使用不同形式表示）
application/x-www-form-urlencoded（POST方法提交的表單）
multipart/form-data（POST提交時伴隨文件上傳的表單）
4.分析文件頭內容來檢查文件類型
與方法2不同，還有一種檢查類型的方式是使用對於文件內容的驗證機制，這種方法利用的是每一個特定類型的文件都會有不太一樣的開頭或者標志位。可以通過比如php的exif_imagetype()函數，一個通過這種方法來過濾的示例代碼如下：
if (! exif_imagetype($_FILES['uploadedfile']['tmp_name'])) {
echo "File is not an image";
return;
}
也可以自己編寫函數來進行識別，圖片文件通常有稱作幻數的頭位元組，我們來看一下幾種圖片文件的幻數：
（注意！下面是二進制而不是文本格式的數據）
JPG
FF D8 FF E0 00 10 4A 46 49 46
GIF
47 49 46 38 39 61
(相當於文本的GIF89a)
PNG
89 50 4E 47
通過檢查頭幾位位元組，可以分辨是否是圖片文件
如果是其他類型的二進制文件，也有響應的頭位元組，如下表
反制
給上傳腳本加上相應的幻數頭位元組就可以，php引擎會將
（一般不限制圖片文件格式的時候使用GIF的頭比較方便，因為全都是文本可列印字元。）
GIF89a
do_something();
?>
如果是其他類型的二進制文件，也有響應的頭位元組，如下表
格式
文件頭
TIFF (tif)
49492A00
Windows Bitmap (bmp)
424D
CAD (dwg)
41433130
Adobe Photoshop (psd)
38425053
Rich Text Format (rtf)
7B5C727466
MS Word/Excel (xls.or.doc)
D0CF11E0
MS Access (mdb)
5374616E64617264204A
ZIP Archive (zip)，
504B0304
RAR Archive (rar)，
7221
Wave (wav)，
57415645
AVI (avi)，
41564920
Real Media (rm)，
2E524D46
MPEG (mpg)，
000001BA
MPEG (mpg)，
000001B3
Quicktime (mov)，
6D6F6F76
Adobe Acrobat (pdf)，
255044462D312E
Windows Media (asf)，
3026B2758E66CF11
MIDI (mid)，
4D546864
5.限制Web Server對於特定類型文件的行為
導致文件上傳漏洞的根本原因在於服務把用戶上傳的本應是數據的內容當作了代碼，一般來說，用戶上傳的內容都會被存儲到特定的一個文件夾下，比如我們很多人習慣於放在 ./upload/ 下面要防止數據被當作代碼執行，我們可以限制web server對於特定文件夾的行為。
大多數服務端軟體都可以支持用戶對於特定類型文件的行為的自定義，以Apache為例：
在默認情況下，對與 .php文件Apache會當作代碼來執行，對於 html,css,js文件，則會直接由HTTP Response交給客戶端程序對於一些資源文件，比如txt，doc，rar等等，則也會以文件下載的方式傳送的客戶端。我們希望用戶上傳的東西僅僅當作資源和數據而不能當作代碼
因此可以使用伺服器程序的介面來進行限制
以Apache為例,我們可以利用 .htaccess 文件機制來對web server行為進行限制
在這里插一句，如果不是專門的文件下載目錄，請務必關掉文件夾瀏覽的許可權，以防止嗅探和可能的越權，也是使用.htaccess文件，在其中加上一句
Options All -Indexes
即可。
禁止腳本執行有多種方式可以實現，而且分別有不同的效果，我們分別來看一下
1.指定特定擴展名的文件的處理方式,原理是指定Response的Content-Type可以加上如下幾行
AddType text/plain .pl .py .php
這種情況下，以上幾種腳本文件會被當作純文本來顯示出來，你也可以換成其他的Content-Type
2.如果要完全禁止特定擴展名的文件被訪問，用下面的幾行
Options -ExecCGI
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi識別
在這種情況下，以上幾種類型的文件被訪問的時候，會返回403 Forbidden的錯誤
3.也可以強制web伺服器對於特定文件類型的處理，與第一條不同的是， 下面的方法直接強行讓apache將文件識別為你指定的類型，而第一種是讓瀏覽器
ForceType text/plain
看代碼就可以很明白的知道，符合上面正則的全部被認為是純文本，也可以繼續往裡面加入其他類型。
4.只允許訪問特定類型的文件
order deny,allow
deny from all
在一個上傳圖片的文件夾下面，就可以加上這段代碼，使得該文件夾裡面只有圖片擴展名的文件才可以被訪問，其他類型都是拒絕訪問。
這又是一個白名單的處理方案
永遠記得，白名單是最有保障的安全措施
可以通過 move_uploaded_file 函數把自己寫的.htaccess 文件上傳，覆蓋掉伺服器上的文件，來定義文件類型和執行許可權如果做到了這一點，將獲得相當大的許可權。
E. 織夢的漏洞防範
1.清除（./、./install、./dede、./include、./plus、./member 、./images、./uploads、../a、./templets 、./data 、./special、special/index.php）目錄及其文件外其他務必設置許可權為755；
2.修改./dede（後台目錄）為其他名稱，避免使用admin、administrator等敏感名稱；
3.在根目錄./下.htaccess（沒有的話可以新建）中新增如下內容：
#保護.htaccess
<Files .htaccess>
order allow,deny
deny from all
</Files>
#目錄執行php腳本限制
RewriteEngine on RewriteCond % !^$
RewriteRule uploads/(.*).(php)$ – [F]
RewriteRule data/(.*).(php)$ – [F]
RewriteRule templets/(.*).(php)$ –[F]
RewriteRule special/(.*).(php)$ –[F]
RewriteRule images/(.*).(php)$ –[F]
#禁止對無索引文件的目錄進行文件列表展示
Options -Indexes
在網路BAE安裝原版DedeCMS
網路應用引擎（BAE）是網路推出的網路應用開發平台。基於BAE架構，使開發者不需要維護任何伺服器，只需要簡單的上傳應用程序，就可以為用戶提供服務。BAE有能力將原本單機的LAMP架構，變成分布式架構。
使用網路Bae雲平台伺服器安裝原版dedecms的方法
下面PHP站教大家怎麼在網路Bae上安裝原版dedecms
1、打開/install/index.php
查找else if($step==4){ ，（大約122行）在這段代碼下面添加以下代碼：
$host=getenv(『HTTP_BAE_ENV_ADDR_sql_IP』);$port = getenv(『HTTP_BAE_ENV_ADDR_SQL_PORT』);$cfg_dbhost = $host.」:」.$port;$cfg_dbname = 『資料庫名稱』;$cfg_dbuser = getenv(『HTTP_BAE_ENV_AK』);$cfg_dbpwd = getenv(『HTTP_BAE_ENV_SK』);$cfg_dbprefix = 『~dbprefix~』;$cfg_db_language = 『~dblang~』;$dbhost=$cfg_dbhost;$dbuser=$cfg_dbuser;$dbpwd=$cfg_dbpwd;$dbname=$cfg_dbname;$dbprefix=」dede_」;$db_language=」utf-8″;
2、打開/include/common.inc.php
查找 $isSafeMode = @ini_get(「safe_mode」);
修改為：$isSafeMode = false;
F. 降低任何文件上傳漏洞風險的最佳建議
一般來說文件類型限制，文件許可權限制(只讀)，這兩個控制了基本上上傳漏洞就沒問題了。
G. 滲透測試應該怎麼做呢
01、信息收集
1、域名、IP、埠
域名信息查詢：信息可用於後續滲透
IP信息查詢：確認域名對應IP，確認IP是否真實，確認通信是否正常
埠信息查詢：NMap掃描，確認開放埠
發現：一共開放兩個埠，80為web訪問埠，3389為windows遠程登陸埠，嘿嘿嘿，試一下
發現：是Windows Server 2003系統，OK，到此為止。
2、指紋識別
其實就是網站的信息。比如通過可以訪問的資源，如網站首頁，查看源代碼:
看看是否存在文件遍歷的漏洞（如圖片路徑，再通過…/遍歷文件）
是否使用了存在漏洞的框架（如果沒有現成的就自己挖）
02、漏洞掃描
1、主機掃描
Nessus
經典主機漏掃工具，看看有沒有CVE漏洞：
2、Web掃描
AWVS（Acunetix | Website Security Scanner）掃描器
PS：掃描器可能會對網站構成傷害，小心謹慎使用。
03、滲透測試
1、弱口令漏洞
漏洞描述
目標網站管理入口（或資料庫等組件的外部連接）使用了容易被猜測的簡單字元口令、或者是默認系統賬號口令。
滲透測試
① 如果不存在驗證碼，則直接使用相對應的弱口令字典使用burpsuite 進行爆破
② 如果存在驗證碼，則看驗證碼是否存在繞過、以及看驗證碼是否容易識別
風險評級：高風險
安全建議
① 默認口令以及修改口令都應保證復雜度，比如：大小寫字母與數字或特殊字元的組合，口令長度不小於8位等
② 定期檢查和更換網站管理口令
2、文件下載（目錄瀏覽）漏洞
漏洞描述
一些網站由於業務需求，可能提供文件查看或下載的功能，如果對用戶查看或下載的文件不做限制，則惡意用戶就能夠查看或下載任意的文件，可以是源代碼文件、敏感文件等。
滲透測試
① 查找可能存在文件包含的漏洞點，比如js，css等頁面代碼路徑
② 看看有沒有文件上傳訪問的功能
③ 採用…/來測試能否誇目錄訪問文件
風險評級：高風險
安全建議
① 採用白名單機制限制伺服器目錄的訪問，以及可以訪問的文件類型(小心被繞過)
② 過濾【./】等特殊字元
③ 採用文件流的訪問返回上傳文件（如用戶頭像），不要通過真實的網站路徑。
示例：tomcat，默認關閉路徑瀏覽的功能：
<param-name>listings</param-name>
<param-value>false</param-value>
3、任意文件上傳漏洞
漏洞描述
目標網站允許用戶向網站直接上傳文件，但未對所上傳文件的類型和內容進行嚴格的過濾。
滲透測試
① 收集網站信息，判斷使用的語言（PHP，ASP，JSP）
② 過濾規則繞過方法：文件上傳繞過技巧
風險評級：高風險
安全建議
① 對上傳文件做有效文件類型判斷，採用白名單控制的方法，開放只允許上傳的文件型式；
② 文件類型判斷，應對上傳文件的後綴、文件頭、圖片類的預覽圖等做檢測來判斷文件類型，同時注意重命名（Md5加密）上傳文件的文件名避免攻擊者利用WEB服務的缺陷構造畸形文件名實現攻擊目的；
③ 禁止上傳目錄有執行許可權；
④ 使用隨機數改寫文件名和文件路徑，使得用戶不能輕易訪問自己上傳的文件。
4、命令注入漏洞
漏洞描述
目標網站未對用戶輸入的字元進行特殊字元過濾或合法性校驗，允許用戶輸入特殊語句，導致各種調用系統命令的web應用，會被攻擊者通過命令拼接、繞過黑名單等方式，在服務端運行惡意的系統命令。
滲透測試
風險評級：高風險
安全建議
① 拒絕使用拼接語句的方式進行參數傳遞；
② 盡量使用白名單的方式（首選方式）；
③ 過濾危險方法、特殊字元，如：【|】【&】【；】【』】【"】等
5、SQL注入漏洞
漏洞描述
目標網站未對用戶輸入的字元進行特殊字元過濾或合法性校驗，允許用戶輸入特殊語句查詢後台資料庫相關信息
滲透測試
① 手動測試：判斷是否存在SQL注入，判斷是字元型還是數字型，是否需要盲注
② 工具測試：使用sqlmap等工具進行輔助測試
風險評級：高風險
安全建議
① 防範SQL注入攻擊的最佳方式就是將查詢的邏輯與其數據分隔，如Java的預處理，PHP的PDO
② 拒絕使用拼接SQL的方式
6、跨站腳本漏洞
漏洞描述
當應用程序的網頁中包含不受信任的、未經恰當驗證或轉義的數據時，或者使用可以創建 HTML或JavaScript 的瀏覽器 API 更新現有的網頁時，就會出現 XSS 缺陷。XSS 讓攻擊者能夠在受害者的瀏覽器中執行腳本，並劫持用戶會話、破壞網站或將用戶重定向到惡意站點。
三種XSS漏洞：
① 存儲型：用戶輸入的信息被持久化，並能夠在頁面顯示的功能，都可能存在存儲型XSS，例如用戶留言、個人信息修改等。
② 反射型：URL參數需要在頁面顯示的功能都可能存在反射型跨站腳本攻擊，例如站內搜索、查詢功能。
③ DOM型：涉及DOM對象的頁面程序，包括：document.URL、document.location、document.referrer、window.location等
滲透測試
存儲型，反射型，DOM型
風險評級：高風險
安全建議
① 不信任用戶提交的任何內容，對用戶輸入的內容，在後台都需要進行長度檢查，並且對【<】【>】【"】【』】【&】等字元做過濾
② 任何內容返回到頁面顯示之前都必須加以html編碼，即將【<】【>】【"】【』】【&】進行轉義。
7、跨站請求偽造漏洞
漏洞描述
CSRF，全稱為Cross-Site Request Forgery，跨站請求偽造，是一種網路攻擊方式，它可以在用戶毫不知情的情況下，以用戶的名義偽造請求發送給被攻擊站點，從而在未授權的情況下進行許可權保護內的操作，如修改密碼，轉賬等。
滲透測試
風險評級：中風險（如果相關業務極其重要，則為高風險）
安全建議
① 使用一次性令牌：用戶登錄後產生隨機token並賦值給頁面中的某個Hidden標簽，提交表單時候，同時提交這個Hidden標簽並驗證，驗證後重新產生新的token，並賦值給hidden標簽；
② 適當場景添加驗證碼輸入：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字元串；
③ 請求頭Referer效驗，url請求是否前部匹配Http(s)😕/ServerHost
④ 關鍵信息輸入確認提交信息的用戶身份是否合法，比如修改密碼一定要提供原密碼輸入
⑤ 用戶自身可以通過在瀏覽其它站點前登出站點或者在瀏覽器會話結束後清理瀏覽器的cookie；
8、內部後台地址暴露
漏洞描述
一些僅被內部訪問的地址，對外部暴露了，如：管理員登陸頁面；系統監控頁面；API介面描述頁面等，這些會導致信息泄露，後台登陸等地址還可能被爆破。
滲透測試
① 通過常用的地址進行探測，如login.html，manager.html，api.html等；
② 可以借用burpsuite和常規頁面地址字典，進行掃描探測
風險評級：中風險
安全建議
① 禁止外網訪問後台地址
② 使用非常規路徑（如對md5加密）
9、信息泄露漏洞
漏洞描述
① 備份信息泄露：目標網站未及時刪除編輯器或者人員在編輯文件時，產生的臨時文件，或者相關備份信息未及時刪除導致信息泄露。
② 測試頁面信息泄露：測試界面未及時刪除，導致測試界面暴露，被他人訪問。
③ 源碼信息泄露：目標網站文件訪問控制設置不當，WEB伺服器開啟源碼下載功能，允許用戶訪問網站源碼。
④ 錯誤信息泄露：目標網站WEB程序和伺服器未屏蔽錯誤信息回顯，頁面含有CGI處理錯誤的代碼級別的詳細信息，例如SQL語句執行錯誤原因，PHP的錯誤行數等。
⑤ 介面信息泄露：目標網站介面訪問控制不嚴，導致網站內部敏感信息泄露。
滲透測試
① 備份信息泄露、測試頁面信息泄露、源碼信息泄露，測試方法：使用字典，爆破相關目錄，看是否存在相關敏感文件
② 錯誤信息泄露，測試方法：發送畸形的數據報文、非正常的報文進行探測，看是否對錯誤參數處理妥當。
③ 介面信息泄露漏洞，測試方法：使用爬蟲或者掃描器爬取獲取介面相關信息，看目標網站對介面許可權是否合理
風險評級：一般為中風險，如果源碼大量泄漏或大量客戶敏感信息泄露。
安全建議
① 備份信息泄露漏洞：刪除相關備份信息，做好許可權控制
② 測試頁面信息泄露漏洞：刪除相關測試界面，做好許可權控制
③ 源碼信息泄露漏洞：做好許可權控制
④ 錯誤信息泄露漏洞：將錯誤信息對用戶透明化，在CGI處理錯誤後可以返回友好的提示語以及返回碼。但是不可以提示用戶出錯的代碼級別的詳細原因
⑤ 介面信息泄露漏洞：對介面訪問許可權嚴格控制
10、失效的身份認證
漏洞描述
通常，通過錯誤使用應用程序的身份認證和會話管理功能，攻擊者能夠破譯密碼、密鑰或會話令牌， 或者利用其它開發缺陷來暫時性或永久性冒充其他用戶的身份。
滲透測試
① 在登陸前後觀察，前端提交信息中，隨機變化的數據，總有與當前已登陸用戶進行綁定的會話唯一標識，常見如cookie
② 一般現在網站沒有那種簡單可破解的標識，但是如果是跨站認證，單點登錄場景中，可能為了開發方便而簡化了身份認證
風險評級：高風險
安全建議
① 使用強身份識別，不使用簡單弱加密方式進行身份識別；
② 伺服器端使用安全的會話管理器，在登錄後生成高度復雜的新隨機會話ID。會話ID不能在URL中，可以安全地存儲，在登出、閑置超時後使其失效。
11、失效的訪問控制
漏洞描述
未對通過身份驗證的用戶實施恰當的訪問控制。攻擊者可以利用這些缺陷訪問未經授權的功能或數據，例如：訪問其他用戶的帳戶、查看敏感文件、修改其他用戶的數據、更改訪問許可權等。
滲透測試
① 登入後，通過burpsuite 抓取相關url 鏈接，獲取到url 鏈接之後，在另一個瀏覽器打開相關鏈接，看能夠通過另一個未登入的瀏覽器直接訪問該功能點。
② 使用A用戶登陸，然後在另一個瀏覽器使用B用戶登陸，使用B訪問A獨有的功能，看能否訪問。
風險評級：高風險
安全建議
① 除公有資源外，默認情況下拒絕訪問非本人所有的私有資源；
② 對API和控制器的訪問進行速率限制，以最大限度地降低自動化攻擊工具的危害；
③ 當用戶注銷後，伺服器上的Cookie，JWT等令牌應失效；
④ 對每一個業務請求，都進行許可權校驗。
12、安全配置錯誤
漏洞描述
應用程序缺少適當的安全加固，或者雲服務的許可權配置錯誤。
① 應用程序啟用或安裝了不必要的功能（例如：不必要的埠、服務、網頁、帳戶或許可權）。
② 默認帳戶的密碼仍然可用且沒有更改。
③ 錯誤處理機制向用戶披露堆棧跟蹤或其他大量錯誤信息。
④ 對於更新的系統，禁用或不安全地配置最新的安全功能。
⑤ 應用程序伺服器、應用程序框架（如：Struts、Spring、ASP.NET）、庫文件、資料庫等沒有進行相關安全配置。
滲透測試
先對應用指紋等進行信息搜集，然後針對搜集的信息，看相關應用默認配置是否有更改，是否有加固過；埠開放情況，是否開放了多餘的埠；
風險評級：中風險
安全建議
搭建最小化平台，該平台不包含任何不必要的功能、組件、文檔和示例。移除或不安裝不適用的功能和框架。在所有環境中按照標準的加固流程進行正確安全配置。
13、使用含有已知漏洞的組件
漏洞描述
使用了不再支持或者過時的組件。這包括：OS、Web伺服器、應用程序伺服器、資料庫管理系統（DBMS）、應用程序、API和所有的組件、運行環境和庫。
滲透測試
① 根據前期信息搜集的信息，查看相關組件的版本，看是否使用了不在支持或者過時的組件。一般來說，信息搜集，可通過http返回頭、相關錯誤信息、應用指紋、埠探測（Nmap）等手段搜集。
② Nmap等工具也可以用於獲取操作系統版本信息
③ 通過CVE，CNVD等平台可以獲取當前組件版本是否存在漏洞
風險評級：按照存在漏洞的組件的安全風險值判定當前風險。
安全建議
① 移除不使用的依賴、不需要的功能、組件、文件和文檔；
② 僅從官方渠道安全的獲取組件(盡量保證是最新版本)，並使用簽名機制來降低組件被篡改或加入惡意漏洞的風險；
③ 監控那些不再維護或者不發布安全補丁的庫和組件。如果不能打補丁，可以考慮部署虛擬補丁來監控、檢測或保護。
詳細學習可參考：
H. 什麼是文件上傳漏洞
文件上傳漏洞：
允許用戶上傳任意文件可能會讓攻擊者注入危險內容或惡意代碼，並在伺服器上運行。
任意文件上傳漏洞原理：
由於文件上傳功能實現代碼沒有嚴格限制用戶上傳的文件後綴以及文件類型，導致允許攻擊者向 某個可通過 Web 訪問的目錄上傳任意PHP 文件，並能夠將這些文件傳遞給 PHP 解釋器，就 可以在遠程伺服器上執行任意PHP 腳本。