1. 邏輯越權

1.1. 漏洞原理

邏輯越權漏洞就是當用戶跳過自己的權限限制，去操作同等級用戶或者上級用戶。正常的情況下，當一個用戶去訪問某個資源的時候，首先需要去登錄驗證自己的權限，其次是對數據的查詢，最后返回數據內容。

但是如果在權限驗證這里，出現了驗證不足或者根本就沒有驗證，那么就會導致越權漏洞的出現。并且邏輯越權又分為水平越權和垂直越權。

1.2. 漏洞原因

邏輯越權主要是由于開發人員在對數據的增刪改查的對人員客戶端的請求數據過分相信，未對其進行權限判定而導致的問題。

1.3. 水平越權

1.3.1. 原理

水平越權也就是同等級越權，可以理解為本來A只能夠自己的工資，而通過更換某個ID或者其他的驗證身份的操作，就能夠A去看B的工資。

1.3.2. 漏洞出現位置

水平越權多數會出現在和數據庫進行增刪改查的地方，若用戶在對其進行信息修改的時候，后臺沒對其進行嚴格的校驗的話或者校驗的規則較簡單的情況下，就可能會出現越權漏洞。

1.3.3. 危害

水平越權的危害可以導致用戶的個人信息泄露，冒充別人等。

1.3.4. 案例

這里使用pikachu靶場做案例演示。

1.3.4.1. 登錄賬號

這里首先需要登錄賬號，模擬自己在日常中正常登錄賬號。這里會發現只能看自己的信息，若你有一個暗戀的女同事，但你又不好意思去找她要聯系方式怎么辦？

1.3.4.2. 獲取信息

像上面提到了，想要獲取女同事的聯系方式，那么在查看信息的時候對其進行抓包修改，看看是否能夠獲取到她的信息呢？

可以看到我們抓包后看到username，那么思考我們能夠把這個kobe換成lucy嗎？

1.3.4.3. 修改信息

可以看到在對username處修改后，就能夠獲取女同事的聯系方式了。

1.4. 垂直越權

1.4.1. 原理

垂直越權就是通過自身低權限賬號去執行高權限賬號所能執行的操作。

1.4.2. 漏洞出現位置

垂直越權漏洞可以考慮低權限提升為高權限，比如讓普通的用戶變成管理員用戶。

1.4.3. 條件

其實垂直越權漏洞是需要一定的條件的，需要抓取到高權限用戶的數據包，而抓取這個數據包是有一定的困難的，比如可以盲猜數據包，或者通過網站獲取源碼本地搭建去獲取。

1.4.4. 危害

垂直越權的危害可以導致普通用戶修改他人的密碼，篡改他人信息，依舊個人信息泄露等。

1.4.5. 案例

1.4.5.1. 登錄admin用戶

這里我們要先登錄admin用戶。

1.4.5.2. 抓取數據

這里我們抓取admin用戶添加用戶的信息，并放在重放器中。

1.4.5.3. 登錄普通用戶

這里我們在登錄普通用戶，可以看到這個用戶只能看，并不能添加用戶，由于在登錄驗證的時候，服務端對其認證就是普通用戶

1.4.5.4. 抓取普通用戶的cookie值

這里在抓取到普通用戶的cookie后替換原先放在重放器中admin用戶的cookie值，然后發包。

1.4.5.5. 查看效果

這里在登錄普通用戶的賬號，在發包后刷新頁面就能夠發現添加一個haha用戶。

1.5. 墨者靶場案例

1.5.1. 登錄靶場

打開靶場，根據要求獲取馬春生的個人信息，這邊給我我們一個測試賬號。

1.5.2. 登錄測試賬號

我們通過登錄測試賬號，并且在登錄過程中對獲取到的數據進行抓包。

1.5.3. 分析數據

在對數據進行分析的時候發現，如果修改用戶名，但是我們并不知道馬春生的用戶名，但是我們看到有一個id，那么可否通過對id的修改獲取數據呢？并且通過分析發現這個id就是會員號。

1.5.4. 爆破會員號

這里我們對會員號進行爆破，通過爆破我們也發現很多會員號下面是有數據返回的，但是究竟是哪一個我們不知道。

1.5.5. 前端分析

我們在看前端加載的數據中發現，測試賬號的頭像圖片的加載名和剛剛抓包獲取到的會員號是一樣的。那么會不會圖片名和會員號是一樣的，便于存放？

1.5.6. 查看目標頭像ID

我們這里返回登錄的頁面，查看馬春生的頭像ID也就是會員號，這里我們獲取到馬春生id結尾是16。

1.5.7. 查看信息

我們獲取到目標的id結尾是16，那么我們去查看爆破中id為16的信息。這里我們通過先前的爆破獲取到賬號和密碼，但是密碼是加密的我們對其進行md5解密，獲得以下信息：

賬號：m233241
密碼：9732343

1.5.8. 獲取信息

這里我們通過登錄，成功獲取目標信息。

1.6. 修復防御方案

1. 前后端同時對用戶輸入的信息進行校驗，雙重檢驗機制。

2. 調用功能前驗證用戶是否有權限調用的經驗。

3. 執行關鍵操作前必須進行用戶身份驗證，驗證用戶是否具備操作權限。

4. 直接對象引用的加密資源ID，防止攻擊者對ID進行爆破或者枚舉，對敏感數據進行特殊處理。

5. 對于可控的參數進行嚴格的檢查與過濾。

2. Autorize插件

2.1. 插件介紹

Autorize是一個幫助滲透測試人員檢測授權漏洞的擴展，這是Web應用程序滲透測試中比較耗時的任務之一。

只需要將低權限賬戶的cookie值交個插件，然后用高權限的賬號登錄網站即可，該插件會自動重復每一個請求與低權限用戶的會話并對其進行檢測。

2.2. 插件狀態

有3種強制狀態：

繞過！-紅色
強制執行！-綠色
是否強制執行？？？（請配置強制檢測器）-黃色

2.3. 插件安裝

2.3.1. 安裝Jython環境

Autorize插件使用python寫的。所以需要使用Jython環境，簡單說就是在Java環境中運行python程序的工具，所以先下載該環境（Jython Standalone即可），然后在下載插件。Jython

若下載慢可以使用我保存的： 提取碼：fmvs

2.3.2. Jython配置

2.3.3. 安裝Autorize

Autorize是可以在插件庫里面直接找到的，bur軟件版本態度可能沒有插件庫，那么就需要直接去下載了，下載地址

這里需要刷新一下，并且點擊這個插件，不然可能會出現依舊無法安裝的情況。

2.4. 插件案例

2.4.1. 抓取普通用戶cookie

首先這里需要抓取普通用戶的cookie值，然后把cookie值發送到下面的信息框中。

2.4.2. 高權限用戶訪問

在把低權限的cookie值發送后，我們開啟autorize插件的開關，然后使用高權限進行訪問網站。

2.4.3. 插件效果

我們在登錄高權限后，進行瀏覽就會產生效果。

2.4.4. 插件顏色介紹

在結果中看顏色，紅色代表存在越權、黃色代表不確定、綠色代表沒問題。在左邊一列中紅色列代表存在越權的可能，右邊一列中紅色列代表存在未授權訪問的可能。

2.4.5. 查看響應數據

可以點擊三個數字和后面的效果可以看到相應的響應數據。如果在響應中存在一些相應的敏感數據，或者查看到相關的增刪改查的post請求就可以報相應的漏洞問題了。

3. 支付漏洞

3.1. 介紹

支付漏洞在漏洞中一直是處于高風險漏洞，對于企業來說相應的危害是很大的，同樣對于用戶的風險也很大的，比如當攻擊者通過修改，使用他人賬號的余額進行購買，那么就屬于支付中的越權漏洞了。

3.2. 購買流程

選擇商品和數量——產生訂單——選擇郵寄地址及支付方式——訂單支付——完成支付。

3.3. 支付漏洞分類

參考鏈接：支付漏洞之總結

3.3.1. 修改支付價格

對于修改支付價格，通常來說購買一件物品需要選中自己所需購買的物品，其次確認相關的信息，最后支付價錢，而在這個過程中，可以在選中時就修改價格，若有相關的驗證，則可以向后邊退，一步一步測試。

3.3.2. 修改支付狀態

其實這里的支付狀態挺好理解的，把支付未成功修改為支付成功即可，這個也是由于支付的狀態未和實際訂單的支付狀態進行校驗而產生的。

3.3.3. 修改購買數量

在支付的過程中，數量也同時決定著價格，比如：1個數量商品對應的是100，2個數據就是200，那么當你修改這個值數量值為負數時，那么其金額也會變為負數，最后就會導致支付問題的產生。

3.3.4. 替換支付

替換支付簡單來說，首先去產生兩個訂單，但是這兩個訂單的商品是不一樣的，其價格也是不一樣的，如果服務端未做好相應的驗證，那么在支付過程中去替換數據，最后支付，這時候就可以使用訂單支付的價格購買到其他貴的物品。

3.3.5. 越權支付

在支付當中會出現當前用戶的ID，比如：username=XXXXX，如果沒有加以驗證，其支付也是一次性支付沒有要求輸入密碼什么的機制，那么就可以修改這個用戶ID為其它用戶ID，達到用其他用戶的賬號進行支付你的商品。

3.3.6. 修改優化價

比如一些商品有優惠價，優惠多少多少，那么在支付時抓包，修改這個優惠價就可造成支付問題的產生。

3.4. 支付漏洞常見篡改參數

商品的ID編號、購買價格、購買數量、支付方式、訂單號、支付狀態等。

3.5. 支付漏洞案例

這里我們安裝大米cms_5.4，在這個大米5.4電子商城是存在邏輯支付漏洞。

3.5.1. 獲取源碼

下載鏈接：大米cms5.4提取碼：onew

3.5.2. 大米靶場安裝步驟

這里安裝靶場很簡單直接把里面的內容解壓到phpstudy中，然后訪問http:你的靶機ip/dami_5.4。

3.5.2.1. 安裝靶場

1）由于這里我們還沒有開始安裝，需要先按照以下步驟進行安裝CMS。

2）這里也是選擇繼續。

3）這里的數據庫密碼和數據庫名字可以根據自己的服務器來設置，如果是服務器的數據庫是默認的賬號密碼，那么密碼就是root，至于管理員設定的密碼，隨便怎么設置吧。

1. 成功安裝。

   

3.5.2.2. 注冊賬號

這里我們需要先注冊一個賬號，用于來購買物品，這里我就創建一個test/test。

3.5.3. 修改支付價格案例

3.5.3.1. 選擇商品

其實這個修改支付價格案例，比較簡單，而且正常來說，這個地方應該也是比較難實現的，可以看到大米測試產品是6000元。

3.5.3.2. 抓取數據包

我們通過抓取購買的數據包修改支付價格，可以看到原來是6000元。

3.5.3.3. 修改數據包

這里我們改成100測試一下效果，修改后的數據包就不發了，直接看效果。

3.5.4. 替換支付案例

3.5.4.1. 選擇貴的商品

替換支付就是抓取貴的數據包替換便宜的數據庫實現使用便宜的價格購買貴的商品，而使用到這種方式就是在假設我們無法直接修改金額的情況下，我們可以使用這種替換方式，這里我們先選擇貴的手機。

3.5.4.2. 抓取貴的商品數據包

抓取貴的數據包，然后放在重放器中，暫存。

3.5.4.3. 選擇便宜的商品

我們選擇購買一個便宜的手機，直接購買，抓取數據包，就不展示便宜的界面了。

3.5.4.4. 對比數據包信息

這里我們對比兩個數據包的信息。

5400的數據包
GET /dami_5.4/index.php?m=Member&a=gobuy&iscart=0&id=70&name=%E5%A4%A7%E7%B1%B3%E6%89%8B%E6%9C%BACMS&qty=1&price=5400&gtype=%E7%81%B0%E8%89%B2&pic=/dami_5.4/Public/Uploads/thumb/thumb_1393218295.jpg HTTP/1.1
6000的數據包
GET /dami_5.4/index.php?m=Member&a=gobuy&iscart=0&id=127&name=%E5%A4%A7%E7%B1%B3%E6%B5%8B%E8%AF%95%E4%BA%A7%E5%93%81&qty=1&price=6000&gtype=%E7%81%B0%E8%89%B2&pic=/dami_5.4/Public/Uploads/thumb/thumb_1393218295.jpg HTTP/1.1

3.5.4.5. 修改數據包

這里我們看到只有ID和金錢不同和圖片不一樣，其他的都是一樣的。那么這里我們就修改id，當然為了更只管點，我們替換id和圖片來顯示。

3.5.4.6. 疑惑

其實到這里就結束了，但是我有一個疑惑的地方，我替換商品后，雖然價格便宜了，會不會導致我購買的物品還是原來便宜的物品？但是后來我考慮到一個問題，我是在同一家購買的，我替換ID后，相當于替換了商品，在后臺看到的應該是貴的商品，只是價格便宜了。不知道理解的對不對！

3.6. 修復防御方案

1. 對商品的價格進行判斷，不能為負數。

2. 商品的價格以數據庫的為準，不能以頁面為準。

3. 設置類似的token值來對數據包進行唯一性處理

4. Cookie脆弱性

4.1. cookie原理

1. 用戶在客戶端 (一般為瀏覽器) 中訪問某個頁面 ，也就是向服務器發送請求。

2. 服務器收到請求后，會在響應頭中設置Set-Cookie字段值，該字段存儲相關信息和狀態。

3. 客戶端解析服務器HTTP響應頭中的Set-Cookie字段，并以key=value的形式保存在本地，之后客戶端每次發送HTTP請求時，都會在請求頭中增加Cookie字段。

4. 服務器接收到客戶端的HTTP請求之后，會從請求頭中取出Cookie數據，來校驗客戶端狀態或身份信息。

4.2. Cookie案例

這里我們使用熊海v1版本，這個版本上有很多的漏洞，可以直接對其進行深度的挖掘，這里我們就只涉及Cookie脆弱性。

4.2.1. 獲取源碼

這里找這個熊海v1源碼挺麻煩的，找了很多都需要積分才能下載，很多文章只有解釋，并不會給下載鏈接，可能想鍛煉我們這些小菜鳥吧。這里呢，我就不鍛煉和我一樣的小菜鳥了，畢竟都是菜鳥，哈哈哈哈哈.......

下載地址：熊海提取碼：lldw

4.2.2. 熊海靶場安裝步驟

這里直接把下載的源碼解壓放到phpstudy中就可以了，然后使用瀏覽器對其進行訪問安裝。

4.2.2.1. 靶場安裝

1. 使用瀏覽器訪問：http://你的服務器ip/熊海文件夾名稱/install/，即可進入安裝界面。這里首先需要創建一個數據庫，這里不會找到如何創建數據庫的，直接打開phpstudy中phpMyAdmin進行創建。這里的數據庫名需要填入下面安裝中的。

   

2. 下面的配置就根據自己的服務器信息進行設置。

1. 到這里就安裝成功了。

   

4.2.2.2. 訪問熊海網站

這里只需要訪問http://你的服務器ip/熊海文件夾名/，這樣就可以了。

4.2.3. cookie越權登錄案例

這個越權登錄，其實是基于代碼審計獲取得，也就相當于是白盒測試，若黑盒測試，基本上應該是測試不出來的。

4.2.3.1. 代碼審計

通過查看/inc/checklogin.php，可以看到這里的cookie值就是判斷user是否為空，若不為空就跳轉登錄進去，若為空則會讓你進行登錄。

4.2.3.2. 抓取登錄信息

若直接登錄在頁面后面加上admin，但是我們之前沒有登錄，那么在訪問admin界面的時候就會跳轉至登錄界面，這里我們就抓取跳轉的登錄信息。若這里你抓取到很多的cookie值，那么把瀏覽器清空，在重新獲取。

4.2.3.3. 手動添加cookie值

我們在之前從源碼中了解到，只要保證cookie值不為空就能正常跳轉，那么我們這里就手動添加一下cookie值。這里我輸入的cookie值是cookie=1，當然你也可以換成別的，只要讓其不為空即可。

4.2.3.4. 查看跳轉情況

可以看到這里，修改過cookie值后，成功跳轉至admin用戶管理界面，也就是控制臺。

4.2.3.5. 問題

通過跳轉上去，發現并不能點擊信息，當點擊信息后會自動跳轉回登錄界面，關于這個問題其實一開始我也想不通，能登錄卻不能操作，作用不大呀，想著是不是需要配合其他漏洞。

但是在點擊后發現好像沒有cookie值，然后添加cookie值后發現能夠正常訪問了，然后相通后發現訪問正常還需要抓新的包把cookie繼續添加上去進行放包。

4.2.3.6. 進行評論列表

我們點擊后需要在新的數據包中繼續添加cookie值，不然就會返回登錄界面。

4.2.3.7. 查看評論列表效果

這里可以看到我們已經成功進入評論列表了。

4.3. 越過條件

其實在這里可以看到我們直接輸入了cookie: user=1，那么我們該如何知道這個cookie值需要使用到user呢？所以相對來說挺雞肋的，在實戰中若沒有源碼基本上不可能繞過，所以這多數適合在白盒測試中，如果一定要使用黑盒測試，那么就需要在網上找相應的源碼進行分析，但若別人修改了，那么基本上就是涼涼的節奏，不可能被繞過的。

4.4. 修改防御方案

1. 根據交互所需的傳輸范圍，設置適當的Cookie有效時間

2. 對cookie加密以及數字簽名，并在安全信道中傳輸

3. 用URL參數代替cookie中可能包含的敏感信息

4. 不要在cookie中設置中文

5. 合理設置Cookies中的安全屬性

6. 服務器不應該在同一個主機上同時運行相互不信任的服務

客戶端回顯、response狀態值、驗證碼爆破、找回流程繞過等。

5. 找回流程繞過

5.1. 找回流程原理

簡單來說就是未驗證短信驗證碼與手機的匹配關系（卻驗證了短信驗證碼與圖片驗證碼）服務器端應該是只檢查是否發送過驗證碼，但未驗證驗證碼與手機號的匹配關系，導致任意賬號重置

5.2. 找回流程案例

靶場是墨者學院的一個登錄密碼重置漏洞分析溯源，由于可能存在一些敏感內容可能過不了審，就不截圖了，直接用文字描述吧。

這里其實就是就是重置系統平臺中17101304128手機號的登錄密碼。

5.2.1. 靶場情況分析

正常網站在重置密碼的時候，會先驗證手機號和驗證碼是否匹配，當匹配了才會跳轉到重置密碼的頁面。而這個網站重置密碼和驗證在一個界面，重置的時候以輸入的手機號為主，那么就會造成重置錯誤的出現。同時最大的問題在于重置密碼的時候為對手機號和驗證碼未進行綁定校驗。

5.2.2. 靶場操作步驟

5.2.2.1. 獲取驗證碼

這里首先需要先獲取已注冊手機號在重置密碼時的驗證碼。要把這個驗證碼進行保存，并且要在5分鐘內完成。

5.2.2.2. 填入驗證碼

把剛剛獲取到的驗證碼填入驗證碼框中。

5.2.2.3. 重置密碼

對現在這個手機號進行重置密碼，這里提示不用管，如果按照模擬來說的話，應該是模擬驗證成功的情況。

5.2.2.4. 替換目標手機號

這里在替換目標手機號后，點擊獲取驗證碼，使其觸發驗證碼中的驗證功能。

5.2.2.5. 填入之前驗證碼

在通過獲取驗證碼后，這里我們是收不到目標的驗證碼的，所以我們填入我們之前獲取的驗證碼。

5.2.2.6. 重置成功

這樣就能夠把目標的密碼重置了，可以看到我們已經拿到key了。

6. response狀態值

6.1. response狀態值原理

Response狀態值，就是在服務器發送某個密碼重置的憑據之后，出現特定的響應值(ture，1，ok，success等等，例如響應頭中的HTTP/1.1 200 ok)，而且例如如果回顯值得校驗是發送到客戶端進行，通過對校驗值得使用規則進行分析后，抓包將Response狀態值改為正確的，然后放包，這樣就能夠從而達到重置密碼得效果。

6.2. response狀態值前提條件

關于Response狀態值的驗證需要判斷是否為前端驗證，如果是后端驗證，那么你就算修改成正確的也無法驗證成功，如果頁面以前端結果進行驗證，那么就能夠繞過，也就是說需要根據具體的驗證情況進行繞過。

6.3. response狀態值危害

其實這里的危害和客戶端回顯差不多，都可以通過這樣方式對登錄、重置密碼等進行操作。

6.4. Response狀態值案例

這里的案例操作完好像并不會真正保存，這里就學習一下這個流程，也不錯的，至少知道怎么操作。這里使用PHP云人才系統靶場，安裝和資源在下面章節。

6.4.1. 查看正確狀態值

這里查看正確狀態值和客戶端回顯綁定操作是一樣的，因為沒有驗證碼短信系統，只能使用客戶端回顯進行操作。這里就不操作了直接看狀態值。

這里可以看到正確的狀態值是1。

看頁面也可以看到我們成功綁定了手機號

6.4.2. 查看錯誤狀態值

錯誤的裝填值只需要在驗證碼處隨便輸入一些內容，然后保存，發到重放器里面發送，查看狀態。這里直接看錯誤的狀態值了。

可以看到我的驗證碼是隨便輸入的，錯誤的狀態值是3。

6.4.3. 攔截狀態值

這里修改狀態值能否成功取決于對方是以什么進行驗證，具體解釋我在上面Response狀態值中已經進行解釋了。這里就不解釋了，直接操作。

這里隨便輸入驗證碼，然后抓包，然后攔截狀態值。

6.4.4. 修改狀態值

點擊完攔截請求響應后，放包就能看見狀態值了。

這里我們攔截后，把狀態值修改為1，然后一直放包，如果出現攔截不到的情況，清空瀏覽器記錄，可能存在干擾。

6.4.5. 查看效果

這里查看效果，整個操作，有點自欺欺人了，狀態值是修改了，但是數據庫并不一定會接收這個數據。

7. Token驗證

7.1. Token的原理

基于Token的身份驗證是無狀態的，我們不將用戶信息存在服務器中。當第一次登錄后，服務器生成一個Token便將此Token返回給客戶端，Token是服務端生成的一串字符串，并作為客戶端請求的一個身份令牌，以后再登錄，只需帶上Token請求數據，不需要再次輸入用戶名和密碼

7.2. Token的目的

為了保護憑據的安全，為了減輕服務器的壓力，減少頻繁的查詢數據庫……采用了Token進行身份認證，一般會把token二次保存在cookie或session里面，并且根據cookie和session的過期時間去維護token的過期時間

7.3. Token暴力破解

7.3.1. 前提條件

如果服務器檢測到頻繁的錯誤登錄后，就會將該賬戶鎖定，那么就無法再爆破了，而且這個案例的Token值是由前端生成的，也就是說在頁面中回顯，就像之前提到的客戶端回顯一樣。相當于這里也需要借助Token回顯。

簡單來說就是第一次登錄給你一個token值，這個token值是用于下一次登錄的，這樣就避免了數據庫來回訪問對比，而且這里還在數據包中回顯了，并且沒有加密，就導致這個漏洞了。

7.3.1.1. Token回顯

這里回顯就相當于，這此回顯的內容，會成為下次發送的token值。

7.3.1.2. 驗證Token回顯

這里為了驗證我們先重新獲取一個數據包，然后攔截返回的請求情況。

查看返回的情況，看看token值是多少？這里可以看到token是49373639c355293c49560529267。

我們再看從新情況的包是否token值等于剛剛獲取到的值，可以看到是等于之前獲取到的token值，所以就驗證了我們的猜想。

7.3.2. 正式爆破

7.3.2.1. 獲取數據包

這里我們抓取一個數據包即可。

7.3.2.2. 加載測試器

這里我們把數據包發到測試器中，在位置中，我們首先清除所有，然后選擇音叉（pichfork）。

添加需要爆破的參數，這里我們假設我們的用戶名是對的，所以我們只爆破密碼和token值。

7.3.2.3. 設置載荷1

這里我們先設置1的載荷就是我們的密碼，由于我知道賬號和密碼，所以我就直接隨便寫了幾個，當然你也可以調用外部密碼表進行爆破

7.3.2.4. 設置載荷2

這里把原來的有效負載集設置成1，這個頁面我就不展示了，然后進入選項，把線程調整為1，由于是一個匹配一個的，不能一個線程發多個。

7.3.2.5. 設置重定向

我們一直向下翻，翻到最下面有一個設置重定向把它設置為僅限范圍。

7.3.2.6. 設置響應值

注意這個都是基于載荷2的基礎上設置的，不要設置成載荷1了。

這里找到Grep-Extract—點擊添加（add）—點擊獲得回復，如果點擊過了就是顯示重新獲得回復—找到Token值，雙擊這個值會自動添加的—點擊OK。

7.3.2.7. 設置載荷類型

這里我們需要把載荷類型設置為遞歸搜索，英文我忘記了，尷尬了，burp軟件我找到的一直都是中文的，英文的都是高版本的，我發現挺難用的，而且一些特定的參數，輸入了沒效果。然后下面的框中的內容在設置完上一步后會自動添加的，然后下面的值我們把剛剛抓包獲取到的token值輸入進去即可，然后開始攻擊。

7.3.2.8. 查看攻擊效果

這里找查看攻擊的內容就可以了， 如果多的話，可以使用過濾器進行查找。至于burp的過濾器設置可以百度搜索一下。

8. 驗證碼安全—客戶端回顯

8.1. 客戶端回顯原理

這種就是再調用短信平臺或者郵箱平臺的時候，沒有判定驗證碼和手機號或者郵件進行綁定，并且把驗證碼檢驗直接放在客戶端的返回數據包中，從而導致驗證碼在客戶端中顯示。但是也存在對內容進行加密的情況，若遇到加密，先看看是否能夠解密，若無法解密再想其他辦法。

8.2. 客戶端回顯危害

這個危害就會導致可以隨意的進行登錄、綁定、重置其他人的密碼等。

8.3. 客戶端回顯案例

這里由于沒有網站進行測試，那么這里就口述這個情況。

8.3.1. 發送驗證碼

在部分網站中會使用現驗證郵箱獲取驗證碼或者驗證手機號獲取驗證碼，但是在這些驗證處會出現，在客戶端中進行回顯，也就是按F12看網絡回顯。

8.3.2. 回顯效果

這里截取一下小迪視頻中的演示情況。

8.4. PHP云人才系統靶場安裝

這里還是和上面一樣直接把下載的源碼解壓放到phpstudy中就可以了，然后使用瀏覽器對其進行訪問安裝。

8.4.1. 獲取源碼

下載地址：php云人才系統3.2提取碼：qc8y

8.4.2. 安裝注意

這個云人才系統，不知道我是把虛擬機玩壞了還是怎么了，使用phpstudy2018版本的，切換各種版本都不行，后來下載phpstudy v8.1版本然后調整好了，搞了我一天都懷疑是源碼問題。

8.4.3. 安裝路徑問題1

這里的安裝路徑一定要看清楚了，解壓包里面有一個upload文件夾，把文件夾里面的內容放到根目錄中，不要放文件夾。

8.4.4. 安裝路徑問題2

把里面的內容解壓到根目錄，其他不用動，整體看一下流程吧，以免出錯誤。先看一下這個小皮軟件的首頁設置。

這里點擊網站點擊管理，管理里面有一個打開根目錄，然后把剛剛的upload解壓到根目錄下面，就可以了。

至于訪問，如果放在根目錄的話，可以直接訪問服務器的ip就可以了，它會自動跳轉。

8.4.5. 靶場安裝

1. 使用瀏覽器訪問：http://你的服務器，這里會自動跳轉到安裝解密，如果沒跳轉那么在后面再添加一個/install/index.php就可以了，這里點擊同意。

   

2. 這里會自動對其進行檢測，我們這里直接點擊下一步。

   

3）這里只需要添加一個數據庫的賬號密碼，根據你的實際需求填寫，不要填寫錯了。填寫完就可以點擊確定了。

4）這里會自動創建數據，稍等一會之后就會跳轉到完成安裝了。

8.4.6. 訪問PHP云人才系統

這里的直接點擊就可以了，若退出了，那么可以訪問http://你的服務器ip/upload/index.php即可。

8.5. PHP云人才系統案例

8.5.1. 注冊賬號

這里我們首先要注冊一個賬號。

8.5.2. 完善個人信息

這里我們按照需求完善個人信息，這里手機號可能要按照固定格式填寫，有檢測，如果不想用自己的從網上隨便找一個。

8.5.3. 綁定手機號

這里需要可能有點小問題，這里只能夠回顯手機號的驗證碼，但是替換手機號可能還是不行。不知道是操作問題還是什么。

8.5.4. 發送驗證碼

這里發送驗證碼需要發送兩次，第一次可能不會出現。

8.5.5. 輸入驗證碼

這里就需要把剛剛獲取到的驗證碼輸入進去，然后點擊保存。

8.5.6. 替換驗證碼

把剛剛獲取的驗證碼替換成新的驗證碼。

8.5.7. 成功綁定

這里試了，替換手機號，一直出錯，無法進行綁定，不知道是不是操作錯誤了，這里不用管，但是成功綁定原先的手機號也驗證了客戶端回顯。

9. 驗證碼安全—驗證碼爆破

9.1. 前提條件

短信驗證碼一般由4位后者6位數字組成(還有特殊情況，字母數字組合等等)，若服務器未對驗證時間，次數進行限制，則存在爆破的可能；

9.2. 驗證碼爆破案例

這里只是舉例子，不代表一定是這樣的，只是了解一些爆破的流程。這里還是使用我們的PHP云人才系統靶場。

9.2.1. 抓驗證碼包

可以看到我們這里獲取到的驗證碼是116836。假設我們不知道驗證碼，我設置個116830開始。

9.2.2. 開始爆破

我們針對這個驗證碼開始爆破添加數字，這里我修改成116830開始，我們知道驗證碼是116836，我們就添加到116840吧。

9.2.3. 查找成功情況

這里查找成功其實挺麻煩的，正常情況下還是使用腳本吧，這里是正確的情況，當然我們是已經知道36了。

這個是錯誤的情況。

9.2.4. 修改驗證碼

我們知道驗證碼后，我們修改一下我們的數據包，把驗證碼改成116836，然后放包。

9.2.5. 查看效果

這里我們能看到我們已經成功綁定了

10. 驗證碼安全—驗證碼復用(服務端)

10.1. 驗證碼復用原理

服務器驗證碼復用原理其實簡單來說就是再某種條件下驗證碼并沒有被刷新，然后被惡意利用，或者再使用完后并未被銷毀，而被重復利用。

10.2. 驗證碼復用危害

既然驗證碼可以復用，那么我們是不是就可以考慮使用撞庫的方式進行測試，反正驗證碼不變，那么就可以隨便測試了，但是前提也是登錄不能有次數限制，不然還是不行。

10.3. 驗證碼復用案例(服務端)

這里也是看效果，主要讓其了解相關的原理和方式，這里使用皮卡丘靶場。

10.3.1. 驗證碼錯誤信息

這里我們先來看一下驗證碼錯誤的信息，可以看到當輸錯驗證碼后，會提示驗證碼錯誤。

10.3.2. 驗證碼正確信息

這里為了保證驗證碼正確，能夠出現提示信息，那么我們這里就把密碼輸入錯誤。可以看到驗證碼正確后，那么這里就會顯示賬號或者密碼錯誤。

10.3.3. 抓包修改

其實從上面的情況我們能看到是先驗證驗證碼，驗證碼正確后才會去驗證賬號密碼。

所以這里我們先把驗證碼輸入正確，把賬號和密碼輸入錯誤，然后驗證碼不變，修改賬號和密碼，我們看兩次提示的信息。

第一次信息我們能看到，驗證碼正確的情況下，是提示了賬號和密碼不對。

第二次我們修改了賬號和密碼，驗證碼沒有改，但是理論的情況下，應該是出現驗證碼錯誤的情況，但是這里還是存在賬號和密碼錯的情況。那么就證實了，驗證碼復用的情況。

10.3.4. 驗證情況

這里我們安裝上面的情況，我們來輸入正確的賬號和密碼，看看能不能成功登錄。

可以看到我們這里提示我們賬號密碼錯誤。

這里我們使用皮卡丘靶場中的賬號密碼登錄，我們驗證碼不改，只該了賬號和密碼，我們成功登錄。

11. 驗證碼安全—驗證碼復用（客戶端）

11.1. 驗證碼復用原理

客戶端的復用是由于驗證碼的校驗和生成都是在前端進行的，而且使用抓包軟件后，發送的數據校驗是在后端，不用經過前端的驗證碼的檢查。

11.2. 驗證碼復用危害

這里的危害和服務端的驗證碼危害還是不是一回事，服務端至少可以設置一個驗證碼使用時間或者次數限制，而客戶端直接就跳過前端驗證，只要有驗證碼就可以了。

11.3. 驗證碼復用案例(客戶端)

11.3.1. 抓取數據包

這里我們直接抓包看看，可以看到我們正常發包后顯示賬號或者密碼錯誤。證明驗證碼是正確的。

11.3.2. 修改數據包

這里我們改了一下驗證碼，并且輸入正確的賬號密碼，發現能夠正常登錄，這就驗證了之前提到的，前端的驗證，當后端發送返回包后，不經過前端驗證。

11.3.3. 驗證情況

這里我們看一下放包后的驗證情況，可以看到成功登錄。

12. 驗證碼安全—爆破工具

這個爆破工具，現在已經不更新了，而且是經過封裝的，無法二次開發，這里，并且驗證的成功率比較低，這里就不演示了，感興趣可以去搜索一下。

下載鏈接：PKAV HTTP Fuzzer 1.5.6提取碼：ct7u

網上還有很多的爆破工具，但是想要爆破準確率高，當然還是免不了~~~~

13. 短信轟炸

這里就不具體演示細說了，免得過不了審。

短信轟炸時手機驗證碼中最常見的一種漏洞類型，在測試過程中，對短信驗證碼接口進行重發數據包，導致大量發送惡意短信，而通常短信發送是有60秒的等待，那么就需要調用很多的接口已經數據包來進行發送，這個就需要收集大量的數據了，比較復雜了。

14. Callback調用

14.1. callback解釋

回調函數就是一個通過函數指針調用的函數。如果你把函數的指針（地址）作為參數傳遞給另一個函數，當這個指針被用為調用它所指向的函數時，我們就說這是回調函數。回調函數不是由該函數的實現方直接調用，而是在特定的事件或條件發生時由另外的一方調用的，用于對該事件或條件進行響應。

如果callback的數據能夠被修改，那么就可以和跨站漏洞相結合，當然需要在頁面源碼中搜索傳遞的參數，如果存在，就意味著傳遞的參數會在前端顯示，也就可以構造xss漏洞。

當然前提添加很多，而且這類都是大站，并去本地靶場由于無法調用接口，所以就無法模擬，具體的可以去百度搜索一下。

15. 如何發現這些漏洞

15.1. 解釋

在日常測試漏洞的時候，如果我們對網站一個一個頁面進行測試，那么很費時間，這樣就比較麻煩，而在burp軟件中可以使用爬蟲來爬這個網站，這樣我們再對這些數據包進行搜索相關數據就可以了。

15.2. 具體操作

15.2.1. 抓取網站數據包

這里我們直接在進入頁面的時候對數據進行抓取，然后發送給掃描。

15.2.2. 設置掃描

這里我們設置選擇審計項目，然后點擊ok。

15.2.3. 查看情況

這里我們到目標—網站地圖—內容中查看，注意burp版本不同可能地方也不同哦，需要注意。

15.2.4. 搜索內容

這里我們點擊空白的地方，就會彈出搜索框，我們輸入比如id、user、callback，filename，uid等等。

15.2.5. 搜索結果

這里我們搜索id，可以看到有id的是亮的，沒id的是灰色的。

16. 最后

如果有內容錯誤，或者解釋不到位的還請各位指出，也是互相學習。

網絡安全學習資源分享:

給大家分享一份全套的網絡安全學習資料，給那些想學習 網絡安全的小伙伴們一點幫助！

對于從來沒有接觸過網絡安全的同學，我們幫你準備了詳細的學習成長路線圖。可以說是最科學最系統的學習路線，大家跟著這個大的方向學習準沒問題。

因篇幅有限，僅展示部分資料，朋友們如果有需要全套《網絡安全入門+進階學習資源包》，需要點擊下方鏈接即可前往獲取?

讀者福利 | CSDN大禮包：《網絡安全入門&進階學習資源包》免費分享（安全鏈接，放心點擊）

同時每個成長路線對應的板塊都有配套的視頻提供：?

?大廠面試題

?

視頻配套資料&國內外網安書籍、文檔

當然除了有配套的視頻，同時也為大家整理了各種文檔和書籍資料

所有資料共282G，朋友們如果有需要全套《網絡安全入門+進階學習資源包》，可以掃描下方二維碼或鏈接免費領取~?

讀者福利 |CSDN大禮包：《網絡安全入門&進階學習資源包》免費分享（安全鏈接，放心點擊）?

特別聲明：

此教程為純技術分享！本教程的目的決不是為那些懷有不良動機的人提供及技術支持！也不承擔因為技術被濫用所產生的連帶責任！本教程的目的在于最大限度地喚醒大家對網絡安全的重視，并采取相應的安全措施，從而減少由網絡安全而帶來的經濟損失。