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繞過等等。