Web安全測試（文末送電子書）
今天小編找到了一本web安全測試的電子書，還不錯。有喜歡看電子書的同學可以下載一下。看文末獲取電子書方式.
來看看今天的文章吧
常見問題:
1.XSS(CrossSite Script)跨站指令碼攻擊
XSS(CrossSite Script)跨站指令碼攻擊。它指的是惡意攻擊者往Web 頁面裡插入惡意html程式碼，當用戶瀏覽該頁之時，嵌入其中Web 裡面的html 程式碼會被執行，從而達
到惡意使用者的特殊目的。
測試方法：
在資料輸入介面，新增記錄輸入：
，新增成功如果彈出對話方塊，表明此處存在一個XSS 漏洞。
或把url請求中引數改為
，如果頁面彈出對話方塊，表明此處存在一個XSS 漏洞
修改建議：
過濾掉使用者輸入中的危險字元。對輸入資料進行客戶端和程式級的校驗（如通過正則表示式等）。
Eg:對使用者輸入的地方和變數有沒有做長度和對”<”,”>”,”;”,”’”等字元是否做過濾
2.CSRF與跨站指令碼(XSS)
CSRF與跨站指令碼(XSS)，是指請求迫使某個登入的瀏覽器向易受攻擊的Web應用傳送一個請求，然後以受害者的名義，為入侵者的利益進行所選擇的行動。
測試方法：
同個瀏覽器開啟兩個頁面，一個頁面許可權失效後，另一個頁面是否可操作成功
使用工具傳送請求，在http請求頭中不加入referer欄位，檢驗返回訊息的應答，應該重新定位到錯誤介面或者登陸介面。
修改建議：
在不同的會話中兩次傳送同一請求並且收到相同的響應。這顯示沒有任何引數是動態的（會話標識僅在cookie 中傳送），因此應用程式易受到此問題攻擊。因此解決的方法為
1.Cookie Hashing(所有表單都包含同一個偽隨機值)：
2. 驗證碼
3.One‐Time Tokens(不同的表單包含一個不同的偽隨機值)客戶端保護措施：應用防止
CSRF攻擊的工具或外掛。
3.注入測試
SQL注入是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元
串，最終達到欺騙伺服器執行惡意的SQL命令。
測試方法：
在需要進行查詢的頁面，輸入正確查詢條件 and 1=1等簡單sql語句，檢視應答結果，如與輸入正確查詢條件返回結果一致，表明應用程式對使用者輸入未進行過濾，可以初步判斷此處存在SQL注入漏洞
修改建議：
對使用者的輸入進行校驗，可以通過正則表示式，或限制長度；對以下關鍵字進行轉換等;
| ||alert|and|exec|execute|insert|select|delete|update|count|drop|chr|mid|master|truncate|declare|sitename|netuser|xp_cmdshell|or|+|,|like'|and|exec|execute|insert|create|drop|table|from|grant|group_concat|column_name|information_schema.columns|table_schema|union|where|select|delete|update|order|by|count|chr|mid|master|truncate|declare|or|--|+|,|like|// |
不要使用動態拼裝sql，可以使用引數化的sql或者直接使用儲存過程進行資料查詢存取;
不要使用管理員許可權的資料庫連線，為每個應用使用單獨的許可權有限的資料庫連線;
應用的異常資訊應該給出儘可能少的提示，最好使用自定義的錯誤資訊對原始錯誤資訊進行包裝。
4.登入認證測試
4.1暴力破解
暴力破解是目前最直接有效的攻擊方式，特別對於金融業務來說，很多情況下口令都為6位純數字，很容易被攻擊。本測試項在於檢查認證系統對暴力破解的防護性。
測試方法：
啟動抓包工具，同時開啟瀏覽器輸入使用者登入頁面，輸入使用者名稱、密碼以及驗證碼，進行登入，如果在抓包中存在明文的使用者名稱和密碼，說明存在弱點。
修改建議：
將請求方式從HTTP方式修改為HTTPS方式或者對輸入的使用者名稱和密碼進行加密，在服務端對密碼進行驗證
4.2程式碼註釋
開發版本的Web程式所帶有的註釋在釋出版本中沒有被去掉，而導致一些敏感資訊的洩漏。我們要檢視客戶端能看到的頁面原始碼並發現此類安全隱患。
測試方法：
開啟登陸頁面(或者待測試頁面)，點選瀏覽器郵件，檢視原始碼，檢查原始碼註釋部分是否有敏感資訊洩露，敏感資訊包括以下內容：欄位文字描述、內網 IP 地址、SQL 語句以及物理路徑等等。
修改建議：
請勿在HTML 註釋中遺留任何重要資訊（如檔名或檔案路徑）。
從生產站點註釋中除去以前（或未來）站點連結的跟蹤資訊。
避免在HTML 註釋中放置敏感資訊。
確保HTML 註釋不包括原始碼片段。
4.3 使用者名稱破解
為了進行暴力破解，攻擊者需要知道已存在的使用者名稱，再對該使用者名稱進行攻擊。
測試方法：
在登入介面輸入不存在的使用者名稱和任意的口令，如果提示使用者名稱不存在，則說明存在漏洞；使用正確的使用者名稱和錯誤的口令進行登入，如果提示口令或密碼錯誤，則說明存在漏洞。
修改建議：
伺服器對所有的登陸錯誤原因進行統一的應答，不會提示準確的錯誤提示資訊。
4.4
在缺少鎖定策略和驗證碼設計有問題的情況下，攻擊者可以通過列舉的方式來進行暴力猜解。
測試方法：
在登入頁面，輸入正確的使用者名稱、錯誤的口令以及正確的驗證碼，提交表單，重複10
次，如果系統沒有返回類似賬號鎖定的資訊，則說明存在漏洞。
修改建議：
在使用者進行錯誤登入次數達到系統配置後，需要對該賬號或者該IP進行臨時鎖定，到達解鎖條件後再進行解鎖。
4.5
檢視是否有驗證碼機制，以及驗證碼機制是否完善，避免使用自動化工具重複登入和進行業務操作。
測試方法：
開啟登陸頁面檢視是否存在驗證碼，如果不存在說明存在漏洞。
輸入正確的使用者名稱和口令以及錯誤的驗證碼，如果只是提示驗證碼錯誤，則說明存在漏洞。
選擇驗證碼，點選右鍵，驗證碼是圖片形式且在一張圖片中，如果不是，則說明存在漏洞。
觀察驗證碼圖片中背景是否存在無規律的點或線條，如果背景為純色（例如只有白色）說明存在漏洞。
修改建議：
將驗證碼生成放在在一張進行了混淆處理的圖片上。
4.6
測試方法：
進入系統的口令修改介面，檢視是否必須輸入舊口令，如果不需要則存在漏洞。
修改建議：
使用者修改密碼時必須提供舊密碼，且新密碼不能與舊密碼相同，密碼要有一定複雜度，參見口令規則建議。
4.7 預設賬戶名稱設定
一般系統均設有預設登入使用者，以及超級管理員賬號，如登入賬號過於簡單將易被破解，造成超級許可權洩露。
修改建議：
上線系統清除超級管理員許可權使用者，或增加超級管理員登入名複雜度，不要設定成易猜測的admin、superadmin等名稱。
4.8 錯誤的頁面資訊
404、500等錯誤或警告訊息，可能會洩露敏感資訊。
修改建議：
捕獲異常跳轉至統一錯誤頁面，避免對外洩漏詳細錯誤資訊。
5.會話管理測試未更新
5.1會話標識測試
檢視登入成功後會話標識是否變更。如果未變更，那麼攻擊者就可以通過一些手段（如構造URL）為受害著確定一個會話標識，當受害者登入成功後，攻擊者也可以利用這個
會話標識冒充受害者訪問系統。
測試方法：
啟動抓包工具或瀏覽器自帶開發者模式開啟登入頁面，輸入正確的使用者名稱、口令以及驗證碼，進行登入，登入後，進行任意一項業務操作。如果登入的SessionId和進行業務的SessionId沒有變化，則說明存在漏洞。
修改建議：
對每次請求都從上次請求獲得令牌，服務端對每次互動都進行驗證
檢視是否存在瀏覽器視窗閒置超時後需重新登入的機制
5.2會話超時測試
測試方法：
開啟登入介面，輸入正確的使用者名稱和口令，進行登入，進行一項業務操作，將瀏覽器空閒超過30分鐘，在進行其他業務操作，如果能夠進行其他業務操作，則說明存在漏洞。
修改建議：
需要在後臺進行配置Session的超時時間。
5.3會話清除測試
使用者登出後會話資訊需要清除，否則會導致使用者在點選登出按鈕之後還能繼續訪問登出之前才能訪問的頁面。
測試方法：
進入登入頁面，輸入正確的使用者名稱和密碼，登入成功後，進行一些業務操作，點選登出按鈕，在瀏覽器輸入地址，輸入上面進行業務操作的地址，如果能夠正常返回業務頁面，則說明存在漏洞。
修改建議：
在使用者登出後，必須將使用者的Session資訊以及快取資訊全部清空。
6其他
6.1檔案目錄測試
目錄列表能夠造成資訊洩漏，而且對於攻擊者而言是非常容易進行的。所以在測試過程中，要注意目錄列表漏洞。
測試方法：
通過瀏覽器訪問web 伺服器上的所有目錄，檢查是否返回目錄結構，如果顯示的是目錄結構，則可能存在安全問題；
或使用DirBuster軟體進行測試；
修改建議：
1.針對每個Directory 域都使用Allow 、Deny 等指令設定，嚴格設定WEB伺服器的目錄訪問許可權；
2.刪除Options 指令下的Indexes 設定項；
6.2檔案上傳漏洞
檔案上傳漏洞通常由於網頁程式碼中的檔案上傳路徑變數過濾不嚴造成的，如果檔案上傳功能實現程式碼沒有嚴格限制使用者上傳的檔案字尾以及檔案型別，攻擊者可通過 Web 訪問的目錄上傳任意檔案，包括網站後門檔案（webshell），進而遠端控制網站伺服器。
修改建議：
嚴格限制和校驗上傳的檔案型別、大小等，禁止上傳惡意程式碼的檔案。同時限制相關目錄的執行許可權，防範webshell攻擊。
6.3http請求方法測試
有些Web伺服器預設情況下開放了一些不必要的HTTP方法（如DELETE、PUT、TRACE、MOVE、COPY），這樣就增加了受攻擊面。
測試方法：
使用SoapUI等工具，傳送除get、post以外的方法請求，如接收應答為200ok，代表啟用了不必要的方法。
修改建議：
在tomcat web.xml中增加如下內容：
/* PUT DELETE HEAD OPTIONS TRACE BASIC |
6.4 伺服器安全策略
1.伺服器使用者許可權
執行Web伺服器的作業系統賬號許可權越高，那麼Web遭到攻擊產生的危害就越大。部署到生產環境執行時是不能用root等最高許可權的，一切都給予以最小許可權。
2.關閉無關埠
網路上被攻陷的大多數主機，是黑客用掃描工具大範圍進行掃描而被瞄準上的。所以，為了避免被掃描到，除了必要的埠，例如 Web、FTP、SSH 等，其他的都應關閉。
如：關閉 icmp 埠，並設定規則，丟棄 icmp 包。這樣他人無法 Ping到伺服器，伺服器安全得到提升。
修改方法：丟棄 icmp 包可在 iptables 中， 加入一條語句：-A INPUT -p icmp -j DROP
3.更改預設埠
如：預設的 SSH 埠是 22。建議改成 10000 以上。這樣別人掃描到埠的機率也大大下降。
舉例修改方法：
# 編輯 /etc/ssh/ssh_configvi /etc/ssh/ssh_config# 在 Host * 下 ，加入新的 Port 值。以 18439 為例（下同）：Port 22 Port 18439
# 編輯 /etc/ssh/sshd_configvi /etc/ssh/sshd_config#加入新的 Port 值Port 22Port 18439# 儲存後，重啟 SSH 服務：service sshd restart
測試新埠連線正常後，刪除 Port 22 的配置。同時從 iptables 中， 刪除22埠，新增新配置的 18439，並重啟 iptables。
4.限制IP登入
如能以固定 IP 方式連線伺服器，那麼，可以設定只允許某個特定的 IP 登入伺服器。 設定如下：
# 編輯 /etc/hosts.allowvi /etc/hosts.allow# 例如只允許 123.45.67.89 登入sshd:123.45.67.89
5.使用證書登入 SSH
相對於使用密碼登入來說，使用證書更為安全，具體方法可參見網路資料。
6.5 口令規則建議
規則1：口令長度的取值範圍為：0‐ 個字元；口令的最短長度和最長長度可配置；口令的最短長度建議預設為6個字元。
規則2：口令中至少需要包括一個大寫字母（A‐Z）、一個小寫字母（a‐z）、一個數字字元（0‐9）；口令是否包含特殊字元要求可以配置。
規則3：口令中允許同一字元連續出現的最大次數可配置，取值範圍：0‐9，當取值為 0 時，表示無限制，建議預設為 3。
規則4：口令須設定有效期，最短有效期的取值範圍：0‐9999 分鐘，當取值為0時，表示不做限制，建議預設：5 分鐘；最長有效期的取值範圍：0‐999 天，當取值為 0 時，表示口令永久有效，建議預設：90 天。
規則5：在口令到期前，當用戶登入時系統須進行提示，提前提示的天數可配置，取值範圍：1‐99 天，建議預設：7 天。
規則6：口令到達最長有效期後，使用者再次登入成功但在進入系統前，系統強制更改口令，直至更改成功。
規則7：口令歷史記錄數可配置，取值範圍為：0‐；建議預設：3個。 —
規則8：管理員/操作員/終端使用者修改自己的口令時，必須提供舊口令。
規則9：初始口令為系統提供的預設口令、或者是由管理員設定時，則在使用者/操作員使用初始口令成功登入後，要強制使用者/操作員更改初始口令，直至更改成功。
規則10：口令不能以明文的形式在介面上顯示。
規則11：口令不能以明文的形式儲存，須加密儲存；口令與使用者名稱關聯加密，即加密前的資料不僅包括口令，還包括使用者名稱。
規則12：只有當用戶通過認證之後才可以修改口令。
規則13：修改口令的帳號只能從伺服器端的會話資訊中獲取，而不能由客戶端指定。
6.6 頁面輸入項校驗建議
對輸入引數進行處理，建議過濾出所有以下字元：
[1] |（豎線符號）
[2] & （& 符號）
[3];（分號）
[4] $（美元符號）
[5] %（百分比符號）
[6] @（at 符號）
[7] '（單引號）
[8] "（引號）
[9] \'（反斜槓轉義單引號）
[10] \"（反斜槓轉義引號）
[11] <>（尖括號）
[12] ()（括號）
[13] +（加號）
[14] CR（回車符，ASCII 0x0d）
[15] LF（換行，ASCII 0x0a）
[16] ,（逗號）
[17] \（反斜槓）
圖文