1.客戶端確認－－伺服器沒有采用確認檢查

2.資料庫互動－－SQL注入

3.檔案上傳與下載－－路徑遍歷漏洞，儲存型跨站點指令碼

4.顯示使用者提交的資料－－跨站點指令碼

5.動態重定向－－重定向與訊息頭注入攻擊

6.社交網路功能－－使用者名稱列舉，儲存型跨站點指令碼

7.登入－－使用者名稱列舉，脆弱密碼，能使用蠻力破解

8.多階段登入－－登入缺陷

9.會話狀態－－可推測出的令牌，令牌處理不安全

10.訪問控制－－水平許可權和垂直許可權提升

11.使用者偽裝功能－－許可權提升

12.使用明文通訊－－會話劫持，收集證書和其它敏感資料

13.站外連線－－Referer訊息頭中查詢字串引數漏洞

14.外部系統介面－－處理會話與／或訪問控制的快捷方式

15.錯誤資訊－－資訊洩露

16.電子郵件互動－－電子郵件與命令注入

17.原生代碼元件或互動－－快取區溢位

18.使用第三方應用程式元件－－已知漏洞

19.已確定的Web伺服器軟體－－常見配置薄弱環節，已知軟體程式缺陷

避開客戶端控制元件:

客戶端提交的每一項資料都應該被視為危險和潛在惡意的

隱藏表單欄位：

隱藏的HTML表單欄位是一種表面看似無法修改．可以通過代理工具攔截修改提交請求．

HTML程式碼片段

<form method="post" aciton="Shop.aspx?prod=1">
	Product: iPhone 5 <br/>
	Price: 449 <br/>
	Quantity: <input type="text" name="quantity"> (Maximun quantity is 50)<br/>
	<input type="hidden" name="price" value="449">
	<input type="submit" value="Buy">
</form>
 

這段程式碼，如果使用Burp 攔截提交的表單，修改price的值在傳送給伺服器，就可以隨意修改隱藏的表單的資料．在購物站點，如果把價格修改為負數能成功，不但能收到商品開可以得到退款．

手裡的Java專案:

使用burp攔截資料 修改在提交價格 隱藏的表單

POST /shopping/add_goods_cart.htm HTTP/1.1
Host: 192.168.1.102:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.102:8080/shopping/goods_32769.htm
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Content-Length: 36
Cookie: JSESSIONID=67EA32EBA03BE77B6BAC9D1160420D3A; bdshare_firstime=1537270511344
Connection: close

＃id=32769&count=1&price=208&gsp=19%2C
id=32769&count=1&price=-100.0&gsp=19%2C
 

返回訊息：

HTTP/1.1 200 
Set-Cookie: cart_session_id=e3ddc347-7532-47cf-9f95-0dc7e2f3ffdc; Domain=192.168.1.102
Cache-Control: no-cache
Content-Type: text/plain;charset=UTF-8
Content-Length: 32
Date: Tue, 18 Sep 2018 11:49:13 GMT
Connection: close

{"total_price":-100.0,"count":1}

HTTP cookie:

和隱藏表單欄位一樣，http cookie不顯示在螢幕上，也不能由使用者直接修改．如果程式信任cookie值可攔截修改．

URL引數：

web程式常常使用預先設定的URL引數通過客戶端傳送資料

http://192.168.1.102:8080/shopping/goods_list.htm?gc_id=3&store_id=1

有時候並不希望普通使用者檢視或者修改URL引數．

包含引數的URL載入嵌入圖片，URL載入框架內容，表單使用POST方法並且預設定引數，彈出的視窗等．

Referer訊息頭：

瀏覽器使用訊息頭指示當前請求的頁面URL或提交了一個表單，或引用其它資源．referer訊息頭可用於準確判斷某個特殊的請求由那個URL生成．

Referer: http://192.168.1.102:8080/shopping/goods_98460.htm

當用戶重設定密碼的時候，使用referer訊息頭驗證請求，使用代理伺服器攔截訊息修改為需要的值，就能輕易篡改成功．

模糊資料：

傳送的資料被加密或某種形式的模糊處理，價格保持原樣，就很難去看懂了．攔截各大電商平臺的資料就可以看到價格都被加密了．提交表單後伺服器將會檢查模糊字串的完整性或進行解密處理．

<form method="post" aciton="URL">
	Product: iPhone 5 <br/>
	Price: 449 <br/>
	Quantity: <input type="text" name="quantity"> (Maximun quantity is 50)<br/>
	<input type="hidden" name="price" value="449">
	<input type="hidden" name="pricing_token" value="加密">
	<input type="submit" value="Buy">
</form>

可以嘗試模糊處理所使用的模糊演算法進行解密，可以找一個價格低的數字，比如找一個價格便宜的產品加密後的價格複製過來，放入發給伺服器．還可以提交畸形字串，測試不同字符集錯誤的字串，嘗試攻擊負責對模糊資料進行解密或去模糊處理的伺服器端邏輯．

攻擊驗證機制:

Web應用中最常用的驗證機制是使用HTML表單獲取使用者名稱和密碼，將資料提交給應用程式．絕大部分都採用這種機制．

暴力破解使用者名稱密碼：

一般站點登入輸入使用者名稱和密碼後會提示密碼錯誤或者沒有這個使用者等資訊，在沒有做防禦暴力破解的機制下，就可以使用破解攻擊匯入字典進行攻擊，如今這種情況不是沒有隻是特別少了，而且防護機制有可能會對cookie的值進行遞增處理，到達某個值後會進行拒絕訪問．有些情況即便是鎖定了賬戶，伺服器也會做出響應．

例如：後臺管理頁面有些根本不會對登入做驗證碼或者保護機制的處理．

還可以對使用者名稱進行列舉，列舉幾個使用者名稱發給伺服器，看伺服器做出的響應是否出現差異．

證書傳輸易受攻擊：

使用非加密的HTTP連線傳輸登入證書，處理網路適當位置就可攔截這些證書．即便使用HTTPS，如果應用程式處理證書的方式不安全，證書有可能會洩露．

密碼修改功能：

web程式中有些站點，不允許使用者修改密碼．在頁面中不提供密碼修改功能連線．

無效的使用者名稱，修改密碼中新密碼和確認密碼進行比對，發給伺服器的資料，進行差異的比對．

舊密碼比對新修改的密碼，做出的響應．若有提示，可確定密碼．

忘記密碼功能和修改密碼一樣，忘記密碼功能設計方面的缺點是邏輯中最薄弱的環節．

忘記密碼可能回設定問題，比如：紀念日，生日，喜歡的顏色，某某的姓名等等．猜測這些問題相比去猜測密碼簡單了許多．

有些人的資訊比如生日什麼的，有可能會公開在網際網路上，比如個人資料的顯示等等．

記住密碼功能容易受到本地和其他計算機使用者的攻擊，記住功能通過一個簡單的cookie操作，設定的cookie其中並不包含使用者名稱，而是使用一個持久會話識別符號，提交這個識別符號就可避開登入過程．即便cookie中儲存用於重新識別使用者資訊得到保護，通過跨站點指令碼等漏洞，也可輕易獲得資訊．

使用者偽裝功能：

web應用程式允許特權使用者偽裝成其他使用者，在該使用者許可權訪問．

例如：銀行Web程式允許服務檯操作員口頭驗證電話使用者，將銀行程式會話轉到該使用者的許可權下，以便提供幫助．

偽裝功能通過隱藏功能的形式執行，不受常規訪問控制管理．判斷使用者是否進行偽裝，應用程式可能會信任由使用者控制的資料．

證書確認不完善：

驗證機制強制要求密碼滿足各種要求，大小寫，密碼的長度不能少於幾位，加字元數字組合等等．一些不佳的驗證機制並沒有對這些做處理．不嚴重字元的大小寫，對密碼截斷處理等．

使用一個賬號，嘗試去驗證，刪除最後一個字元，改寫字元大小寫等等．從而利用得到的資訊就可以避免一些多餘的測試，提高成功率．

非唯一性使用者名稱：

自我註冊的應用程式允許使用者指定他們自己的使用者名稱，不強制要求使用者使用唯一的使用者名稱．極其少見，不是沒有可能出現．

註冊階段或修改密碼的過程，共享一個使用者的兩個使用者可能碰巧選擇相同的密碼．導致登陸後共享了資料．

嘗試使用不同的密碼兩次註冊用一個使用者名稱．出現註冊成功就存在這一漏洞．

可預測的使用者名稱：

應用程式根據某種可以預測的順序自動生成使用者名稱．如果以這種方式運轉，弄清使用者名稱順序就可以很快獲得全部有效使用者名稱．

測試提交幾個使用者名稱，讓程式自動生成，進行比對看是否有順序，如果可行便可以使用蠻力攻擊．

可預測的初始密碼：

一些應用程式一次性大批量建立使用者，並自動指定初始密碼．以某種方式將密碼發給使用者．這種生產密碼的方式可以能預測其他使用者的密碼．如果出現根據使用者名稱相關的資訊，就可推斷相應其他使用者的初始密碼．

證書分配不安全：

許多應用程式並不在使用者與應用程式正常互動的過程中分配新建賬號的證書，通過郵件或其他方式．

這種分配方式有時帶來安全風險，例如：傳送郵件中包含使用者名稱密碼，沒有給郵件設定使用的時間限制，沒有要求使用者登入後修改密碼，如果郵箱被訪問，會導致任何人使用此賬號．

有時會方式一個啟用賬號的URL連結，如果發給使用者的URL出現某種順序，就可以通過註冊幾個緊密相連的使用者找到其中的順序．嘗試使用同一個URL看是否會遭拒絕．

故障開放登入機制：

在JAVA程式中如果做異常處理，如果使用者不輸入使用者名稱密碼，出現空指標異常，使用者就可以成功登入．出現機率低，但不是不可能．也有可能出現類似的Bug.

多階段登入機制中的缺陷：

web程式中使用設計好的多階段登入機制，可能出現邏輯上的缺陷．第一階段出現驗證通過，第二階段中沒有驗證通過，有可能直接跳過第二階段驗證，直接在第三階段驗證通過．或者在第一階段驗證出錯，而第三階段通過．

不安全的證書儲存：

web應用程式常常以危險的方式將使用者證書儲存在資料庫中，經過MD5加鹽等操作或另一種加密方式．

雖然到了密碼安全性，但或許可以利用其他的漏洞進行訪問這些證書，例如：SQL注入

攻擊會話管理:

狀態要求:

從本質上講,HTTP協議沒有狀態.它基於一種簡單的請求響應模型,其中對每對訊息帶一個獨立的事務.早期的web程式是任何人都可以查閱的靜態HTML頁面.

執行會話最簡單,最常見的方法是向每名使用者釋出一個唯一的會話令牌或識別符號,使用者在隨後向伺服器請求都提交這個令牌.

多數情況下,都是使用HTTP cookie作為伺服器與客戶端傳送這些會話令牌的傳輸機制.伺服器對新客戶端的請求響應中set-cookie.客戶端隨後的每次請求中都會包含set-cookie的值.

這種標準的會話非常容易遭受攻擊.可以劫持繪畫,由此偽裝成這名使用者.漏洞主要分為兩類:會話令牌生成過程中的薄弱環節和在整個生命週期過程中處理會話令牌的薄弱環節.

會話替代方案:

並非每一種web程式都會使用會話,一些具備驗證機器,功能複雜的安全性至關重要的應用程式選擇使用其他技術管理狀態.常見的會話替代方案有兩種:HTTP驗證和無會話狀態機制.

如果使用HTTP驗證,可能不執行會話管理機制,分析任何可能是令牌的資料的作用.

如果使用無會話狀態機制,向客戶端釋出的可能令牌的資料相當長100B或超過100B,請求的響應,檢視是否有新令牌資料.提交多個相同資料的請求,看是否遭到拒絕.

令牌有一定含義:

一些會話令牌通過使用者名稱或電子郵件地址轉換而來,或者使用與其相關的其他資訊建立.對這些資料進行模糊處理或進行編碼.可對其解碼檢視.

令牌可預測:

會話令牌中不包含與使用者有關的任何有意義的資訊,但它們由包含某種順序,可通過幾個令牌樣本進行分析,推斷最近釋出的其它有效令牌.或許嘗試幾百次到幾千次找到或找不到有效令牌.尋找有效令牌會受伺服器容器,其他使用者的活動,頻寬,網路延長等因素影響.會話令牌通常來自3個方面:隱含序列,時間依賴,生成的數字隨機性不強.

加密令牌:

令牌中包含使用者有意義的資訊,向用戶釋出令牌之前對令牌加密處理來避免出現明顯問題,看是穩妥.但有時候不需要對令牌解密就可直接篡改令牌中有意義的內容.

加密令牌使用對稱加密演算法ECB,出現問題的主要原因是明文分組與密文分組完全對應所致.

在日誌中洩漏令牌:

web程式為管理員和其他人員提供監控和控制程式執行狀態的功能,在日誌中暴露令牌的原因是RUL查詢字串,不使用HTTP cookie或POST請求主體來傳輸令牌.google查詢inurl:jsessionid

攻擊訪問控制:

訪問控制可分為三大類:垂直訪問控制,水平訪問控制和上下文相關的訪問控制.

使用者能夠訪問他無權訪問的功能或資源,訪問許可權控制存在缺陷.分配給他的角色不具有這種許可權,就會出現垂直許可權提升漏洞.如果使用者有資格檢視或者修改檔案,就會出現水平許可權提升漏洞.使用者利用程式中的漏洞獲得關鍵資源的訪問許可權,就會出現業務邏輯漏洞.

完全不受保護的功能: 敏感功能和資料可以被任何相關的URL訪問例如:http://www.xxx.com/admin/  phpmyadmin/ 等等.許多程式使用javaScript在客戶端動態建立使用者介面中使用一些狀態標記.

例如:

if (isAdmin){

    adminMenu.AddItem("/admin/admin.jsp"....);

}

直接訪問方法:程式在使用遠端呼叫API方法的URL引數,這類漏洞通常出現在Java中.訪問許可權沒有受到嚴格控制,可通過引數直接訪問方法.

例如:

http://www.xxx.com/public/admin/getAllUser, getAllRoles, getAllUsers, getCurrentUserPermissions等等

基於識別符號的功能:

訪問某個特殊的資源時,請求資源的識別符號常常以請求引數的形式在URL查詢字串或POST請求主體中提交給伺服器.

如果許可權控制不完善,請求相應的URL使用者都可以檢視無權訪問的內容.

http://www.xxx.com/index.php?id=12323432

靜態檔案:

很多情況下,使用者都是通過在伺服器上執行動態頁面釋出請求來訪問受保護的資源.每個動態頁面負責執行適當的訪問控制檢查,確認使用者擁有的許可權.有些時候,使用者會直接向伺服器Web根目錄下不受保護的靜態資源提出請求.就會導致嚴重的訪問許可權漏洞.

例如在購買電子書的站點: www.xxx.com/download/1223423.pdf  知道這個URL的使用者都可以訪問下載該資源.

配置錯誤:

一些應用程式在Web伺服器或應用程式平臺使用控制元件來控制訪問,程式會根據使用者的角色來限制對特點URL路徑的訪問,如果使用者不屬於管理員,訪問/admin路徑會受到拒絕,如果配置錯誤,就會造成為授權訪問.

GET方法的最初目的是檢索資訊,POST方法是執行更改應用程式的資料或者狀態.

如果程式級指令碼並不驗證對此功能的所有請求是否使用POST方法,就可以通過使用GET方法提交同一請求來避開這種控制.

訪問控制方法不安全:

基於引數的訪問控制:程式在使用者登入時決定使用者的角色或訪問級別,http://www.xxx.com/login/index.jsp?admin=true 

基於Referer的訪問控制:Referer訊息頭完全由使用者控制,可以修改任何值

基於位置的訪問許可權:使用位於所需位置的Web代理伺服器,使用在所需位置終止的VPN,使用支援資料漫遊的移動裝置,直接修改客戶端用於確定地理位置的機制.