常見 WEB 安全漏洞（轉）

SQL注入

成因：程序未對用戶的輸入的內容進行過濾，從而直接代入數據庫查詢，因此致使了sql 注入

漏洞 。

思路：在URL處能夠經過 單引號 和 and 1=1 and 1=2 等語句進行手工測試sql注入 。

Post 注入：好比後臺登陸框輸入單引號測試注入，報錯的話說明存在注入能夠直接抓包，用工具來完成注入。（ 在HTML中關於提交類型代碼，尤爲是後臺登陸和留言這些，都是須要 post 形式來提交的，並且 post 提交方式也是不會像 get 形式在 URL 中顯示的。）

關於SQL注入 還有 ，Cookie注入 盲注 爆錯注入 等等...

實例：

輸入單引號，進行初步判斷，若是報錯就說明可能存在注入。 

而後我，猜測出真正執行的SQL語句應該是： select * from info where fid=623

繼續輸入 and 1=1 ， and 1=2 來看下是否能夠手工注入，就是查看頁面是否存在顯示性錯誤，而不是單引號式的錯誤。

因爲我是轉貼的，因此就沒有這個截圖，可是成功的報錯了。而 and 1=1 和 and 1=2 在SQL 語句中是這樣的：

select * from news where id=623 and 1=1

select * from news where id=623 and 1=2

這樣的語句在數據庫查詢中是能夠查詢成功的 ， 623 and 1=1 而這裏的 and 是一個邏輯判斷符，623是正確存在的，而 1=1 這個也是正確的啊！因此 正確 and 正確 ，就會查詢 623 這個，因此頁面也就返回正常了，而 1=2 這確定不對等，因此 正確 and 錯誤，就會查詢錯誤，因此報錯 。

既然存在注入了，懶的手工就直接扔 sqlmap 了。

XSS 漏洞

原理：web 程序解析了用戶的HTML代碼操做。說白了，就是程序員在設計網站中輸入輸出的部分的時候，沒有對用戶輸入的內容進行過濾，從而致使用戶輸入惡意代碼時，這些代碼會被 web 程序給執行了。

Xss分類：反射型，存儲型，DOM型，FLASH（DOM，FLASH不經常使用）

反射型xss ：存在輸入輸出的地方，不具有轉存數據庫這一步，只是一個簡單的輸入輸出。通常這類的漏洞危害比較小，由於它的傳播方式須要惡意用戶把他構造好的惡意 URL 發給你，你點擊纔會觸發的，通常有安全意識的不多會中招。

存儲型xss ：沒有對用戶輸入的東西，進行過濾，就直接存儲到數據庫中。通常這類的漏洞是危害最大的，並且能夠運用在不少方面上，只要你知識牢固，思惟廣闊，這個漏洞，能夠玩出不少花樣來，不過該漏洞，目前運用最廣的就是在網站留言板這一類的，輸入惡意代碼，讓網站管理員查看後，並中招，從而竊取 cookie 。

反射型實例 ：

反射型（查看url）大白話總結：吃什麼吐什麼

發現php？S=24 (下面的輸出內容爲1，測試下)

發現把s的內容替換以後 頁面的內容也隨之替換，則此處應該存在xss反射漏洞。

那咱們構造下一個經常使用的 javascript 的彈窗代碼，再看下效果 。

回車一下 。 

經過測試，咱們發現這是一個典型的反射型 XSS 漏洞。

儲存型XSS實例：

這是一個存在儲存型 XSS 漏洞釣魚網站 。

而後，咱們鼠標右鍵簡單的查看下網頁源代碼 。

在查看源代碼時，咱們發現 當領取碼不等於98的時候 就返回true，及領取碼等於98。

咱們隨便輸入領取碼以後，就是彈出一個領取獎品頁面，在這個頁面，咱們其實就能夠盲打一下試試。

那麼在開始以前，咱們先隨便找一個 XSS 平臺，複製一段盜取 cookie 的惡意代碼。

Xss插入的地方大多爲標題跟內容（一切能夠輸出文本內容的均可以插入），而後咱們試着插入下。

插入到聯繫地址裏面測試下能不能插入，（前面加個」>)以防萬一閉合下前面的標籤。

#（這裏，我其實不推薦這樣的插入，由於這個的格式，字數限制都是一些 html 這個層面的限制，建議進行抓包插 XSS 代碼，這樣被打到的概率更大。）

到這裏就提交成功了，那就等管理員上鉤就是了。

看來這個釣魚網站的管理員也是個時時關注信息，認真負責的管理啊！不像某些公司的那些運維們，大半年的後臺都不進，我記得我一個朋友，前段時間，發了一個說說，大概內容是 mlgbz ，兩年前插的一個留言板，我今天居然收到這個 cookie 了。。。

解析漏洞：

利用web中間件自身的漏洞，對畸形腳本格式進行了解析。

這個很少解釋，程序自身研發時的問題。

IIS 6.0

常見組合：server 2003+IIS6(IE6.0)

1. 正常解析格式包括：asp,asa,cer

2. 正常解析 1.asp;.jpg | 1.asa;.jpg | 1.cer;.jpg | 1.asp;xxxx.pdf

3. 正常解析 1.asp文件夾下的任意文件: 好比說網站目錄中有一個文件夾名爲1.asp ，那麼這個文件夾下的任意文件，好比1.jpg,1.pdf,1.doc,1.abc 都會解析成asp腳本文件。再好比有一個連接：

http://www.zhutougg.com/abc.asp/1.pdf

若是該站的中間件爲IIS6.0,那麼這個連接就會解析成asp腳本。

備註：在利用上傳漏洞的時候，若是不能上傳asp格式文件，先嚐試上傳asa,cer格式，而後再嘗試上傳1.asp;.jpg格式文件，若是能夠控制上傳後的目錄，就上傳test.jpg圖片大馬到1.asp目錄下。

IIS 7.5

常見組合：server 2008+IIS7/IIS7.5

1. 若是目標能解析PHP腳本，則能夠嘗試上傳1.jpg,而後訪問 http://www.test.com/1.jpg/1.php 或者 http://www.test.com/1.jpg%00.php
APACHE 2.2.*

常見漏洞版本爲2.0.*到2.2.*

apache 文件解析方式: 文件名由右往左解析。即 1.jpg.pdf　　apache 會先識別 pdf格式，而後再識別 jpg 格式，由於 apache 可以識別 pdf 格式，因此這裏它不會解析 .jpg 格式。再好比　1.jpg.abc apache 先識別 .abc 格式，再識別 .jpg 格式，這裏 apache 不認識 .abc 格式，因此這裏 apache 將其解析成 .jpg 格式 。

利用：上傳1.php.abc 1.jpg.abc.php.123.rar(?)

NGINX 0.5.* | 0.6.* | 0.7-0.7.65 | 0.8-0.8.37

若是目標能解析PHP腳本，則能夠嘗試上傳1.jpg,而後訪問 http://www.test.com/1.jpg/1.php 或者 http://www.test.com/1.jpg%00.php

備註：在碰到 nginx 中間件時候，先找到網站的圖片連接好比 http://blog.zhutougg.com/content/images/2016/11/1-2.png ,而後直接在連接後面加上 %00.php

其它常見的中間件：

asp , aspx： iis5.0 , iis6.0 , iis7.0 , iis7.0 , iis8.0

php: apache , nginx , fast-cgi

jsp: tomcat , weblogic , jboss , jetty , GlassFish , Resin , IBM Websphere

aspx的兄弟格式： ashx

jsp: jspx

實例：asp解析漏洞

進入網站以後隨手測試下注入點（http://xxx/detail_industry_news.asp?id=6）

手工測試以後發現存在sql注入 ，而後就扔注入工具裏 。

可是沒有注入出來表單，後來又換了多個注入工具進行注入，結果同樣，都沒有表單數據 。

而後使用目錄掃描器進行掃描，發現有一個webdata二級目錄，本身猜想會不會是數據庫文件了？

而後，繼續掃描二級目錄發現 webdata/webdata.mdb 這個數據庫文件，下載以後發現帳號，密碼。

既然，帳號密碼都有了，那就找後臺吧 。

目錄掃描器，掃後臺沒找見 = =！ 那好吧，手工慢慢找 。。。

最後在一個旁站的 robots.txt 文件裏，發現一個特色，就是它這個旁站的後臺是域名格式的後臺，那主站是否是也是這個了？搞！

沒想到還真是 xx.xx/xx.xx 這樣後臺 。。。

那就進後臺 。

一股濃濃的南方站的味道，就像吃老乾媽的感受同樣，那就先找數據庫功能吧 。

額，沒有數據庫備份這個功能，看來數據庫備份拿 shell 這個方法是不行了。。。

不過這個站是 IIS6.0 的，存在解析漏洞，還好日 ，那就找上傳點吧 。

找到一個上傳點，先傳個正常圖片看看，看這個上傳點是否是壞的，還有會不會出來路徑 。

既然不是壞的，那就上傳個 asp DAMA 吧 。

看來不能直接上傳，那好吧，抓包上傳吧 。

因爲，咱們事先知道了上傳路徑 /bookpic/ ，因此咱們直接利用 IIS 6.0 的解析漏洞，也就是 

（1.asp;.xx）{xx是上傳文件的名字} 在文件夾後面加上 1.asp; 試試能夠上傳成功並解析嗎。

抓包 ，改包 ，來先看看 。

來，看看咱們能不能連上這個 DAMA 。

結果很不賴，被解析了，從而，也就拿下這個站了。

上傳漏洞加繞過方法

客戶端檢測 ：

程序員通常使用 JavaScript 來拒絕非法文件上傳。

繞過方法：

FireBug插件：將用於檢驗文件擴展名的onsubmit事件刪除。

中間人攻擊：使用Burp Suite。首先把木馬擴展名改成一張正常圖片的擴展名，好比JPG擴展名，在上傳時使用Burp Suite攔截上傳數據，再將其中的擴展名JPG修改成PHP，就能夠繞過客戶端驗證。（可能還須要相應地修改Content-Length）

任何客戶端驗證都是不安全的。客戶端驗證是防止用戶輸入錯誤，減小服務器開銷，而服務器端驗證才能夠真正防護攻擊者。

服務器端檢測

白名單與黑名單驗證

黑名單過濾方法：定義不容許上傳的文件擴展名

黑名單的繞過方法：

1.攻擊者能夠從黑名單中找到Web開發人員忽略的擴展名，如：cer

2.對文件的後綴名進行大小寫轉換，好比黑名單中有php，能夠將文件的後綴改成pHp，僅限windows平臺

3.在windows系統下，若是文件名以「.」或者空格做爲結尾，系統會自動刪除「.」與空格，利用此特性也能夠繞過黑名單驗證。（asp.或asp_）

白名單過濾方法：定義容許上傳的文件擴展名

白名單的繞過方法：結合Web容器的解析漏洞

MIME驗證

php 中經過 $_FILE['file']['type'] 來檢驗

繞過方法：能夠在Burp Suite中更改Content-Type的內容爲image/jpeg

目錄驗證

在文件上傳時，程序一般容許用戶將文件放到指定的目錄中，若是指定的目錄存在，就將文件寫入目錄中，不存在的話則先創建目錄，而後寫入。

好比：在前端的HTML代碼中，有一個隱藏標籤<input type="hidden" name="Extension" value="up"/>

在服務器端有以下代碼：

if(!is_dir($Extension)){ //若是文件夾不存在，就創建文件夾
mkdir($Extension);
}

攻擊者能夠利用工具將表單中value的值由「up」改成「pentest.asp」，並上傳一句話圖片木馬文件。

程序在接收到文件後，對目錄判斷，若是服務器不存在pentest.asp目錄，將會創建此目錄，而後再將圖片一句話密碼文件寫入pentest.asp目錄，若是Web容器爲IIS 6.0，那麼網頁木馬會被解析。

00截斷上傳

在ASP程序中最多見，也就是%00將後面的字符都截斷了，好比上傳文件名爲1.asp%00xxser.jpg。

實際操做過程當中，利用Burp Suite的Repeater中的HEX選項卡能夠進行這樣的操做。

截斷上傳漏洞不只出如今ASP程序上，在PHP、JSP程序中也存在這樣的問題。

0x00不是針對全部基於白名單的後綴名檢查都能繞過，代碼的實現過程當中必須存在截斷上傳漏洞。

邏輯漏洞分類

欺騙密碼找回功能（任意密碼重置等）

程序根據一個驗證碼來肯定是用戶本人，攻擊者能夠經過抓包改包，暴力破解，等方法來進行繞過。（漏洞產生的緣由：前端驗證，數據包中含CODE等）

思路：fuzz模糊測試來進行漏洞挖掘

實例：某學院存在任意密碼重置漏洞

第一步（先找回密碼）> 查看源代碼

跟一下 nextDo2

關鍵在跳轉第二步

若是data.status 等於0 那麼跳轉第二步，若是不等於0 那麼就提示驗證碼不正確！

只要 status 等於0 它就跳轉第二步，那麼經過burp去修改它的 Response

放包以後就會發現直接繞過驗證改密，這樣就造成了任意密碼重置漏洞。

預防思路：response數據內不包含驗證碼，驗證方式主要採起後端驗證。

任意金額修改

能夠經過篡改數據報，使得購買的商品價格爲負數等（金額數據經過明文傳輸，沒有後端驗證等一系列均可以產生任意金額修改漏洞）

實例：

註冊下單，支付，選擇拉卡拉支付

截斷 http 請求，更改post金額數據 。

到達支付頁面發現 ，

發現金額被修改，也未提示該修改無效 。

預防方法：後端驗證，數據包加密後進行傳輸 。

越權漏洞

主要是由於開發人員在對數據進行增、刪、改、查詢時對客戶端請求的數據過度相信而遺漏了權限的斷定（僅限於存在漏洞功能對應的數據）

思路：

可能出現越權漏洞的地方（對數據庫進行操做的均可以）。

查看代碼 當id=數組裏面的數爲則顯示帳號密碼，不然輸出信息出錯。

當知道管理員的id的時候能夠任意更改url查詢到帳號密碼。

固然越權漏洞存在不少種cookie繞過等等。