安全测试基础 -- 概述【转载】
一般來說，版本功能測試完成，對應的用例也實現了自動化，性能、兼容、穩定性測試也完成了以后，我們就需要考慮到系統的安全問題，特別是涉及到交易、支付、用戶賬戶信息的模塊，安全漏洞會帶來極高的風險。
?
一．安全測試原則與常見的安全威脅：
1.安全需求：
※認證:對認證的用戶的請求返回
※訪問控制：對未認證的用戶的權限控制和數據保護
※完整性：用戶必須準確的收到服務器發送的信息
※機密性：信息必須準確的傳遞給預期的用戶
※可靠性：失敗的頻率是多少？網絡從失敗中恢復需要多長時間？采取什么措施來應對災難性的失敗？（個人理解這個地方應該更偏向于容錯容災測試的范疇）
※不可抵賴：用戶應該能證明接收到的數據來自特定的服務器
2.常見的安全測試內容
權限控制
SQL注入
URL安全測試
XSS（跨站腳本攻擊）
CSRF（跨站請求偽造）
URL跳轉漏洞
其他安全方面的考量
接下來，我們以一個C#實現的下常見的MVC架構網站為例，來分析具體的各個安全測試角度。
?
二.權限控制
權限控制相對來說比較簡單，功能測試的過程中也接觸過不少，主要就是考慮以下方面：
1.用戶權限：我們假設存在兩個用戶A,B；其中A的權限級別很高，B的權限級別則很低：
只有A能進行的操作，B能不能進行操作；
只有A能看到的頁面，B能不能看到；
2.頁面權限：
必須登錄才能看到的頁面，不登錄直接訪問能否看到？
必須A-B-C的頁面，能否直接A-C？
通常來說單純的權限控制頁面測試不復雜，但是因為權限控制和后續的URL跳轉、Session等方面結合的比較緊密，所以單獨提出來。
?
三.SQL注入
通過構造符合SQL語法的參數傳入程序，通過執行SQL語句進而執行攻擊的操作；原因是程序完全信任了傳入的數據，致使非法數據能夠入侵系統。
解決方案：
一些措施，如：
盡量避免使用動態構造SQL，而是使用SqlParameter對參數進行格式化或使用框架提供的一些功能，分離控制語句與執行語句；
對傳入的字符進行轉義處理，’和%、_、[]等通配符進行轉義處理，保證執行SQL的時候這些字符是正確在字符串內進行處理的；
在前端表單或控件中增加驗證，保證傳入后臺的數據是合法的；
數據庫權限控制，只給對應功能需要的權限，比如登錄頁面只能進行查詢，不賦予其執drop、update、delete、truncate等操作的權限。
?
四.URL安全測試：
1.MVC下的URL構成：
1).使用Get方式的URL構造方式：
~/控制器名/調用的方法?入參1=參數1&……&入參n=參數n，例如：
http://localhost:10344/AbnormalPunch/ApplySubmit?ID=13244&EmployeeID=1D2DE5AD8BC74E2A9CA70DE3567472EB
可以看到，在不經過處理的情況下，Get方式生成的URL可以看到數據和參數
2).使用Post方式的URL構造方式：、
~/控制器名/調用的方法，入參則放在報文實體主體部分中，例如：http://localhost:12688/Order/OrderList
通過接口測試手段可以獲取到訪問的入參：
{
??? "OrderType": "0",
??? "QueryType": "1"
}??
?
URL安全測試主要是基于URL的構成方式進行的測試，很多時候會涉及到和其他方向的交叉；了解各個原理后，就能比較全面的考慮問題了。
2.參數檢查：主要就是檢查URL或者主體報文中的參數
使用Get方式時，URL中顯示的參數正確；敏感參數如用戶名、密碼不應被顯示；
使用Post方式時，敏感參數應該進行加密處理
極端但是比較安全的處理方式是URL只顯示網站地址，
3.根據URL的構成方式直接篡改URL：
我們回過頭去看這個URL：
http://localhost:10344/AbnormalPunch/ApplySubmit?ID=13244&EmployeeID=1D2DE5AD8BC74E2A9CA70DE3567472EB
這個URL的內容是的查詢某個用戶提交的某個申請的明細，URL的傳入的ID為要查詢的申請，EmployeeID是從Session中取的當前登錄用戶的ID。
那么我們可以基于以下場景篡改URL進行驗證：
用戶未登錄時，直接輸入該網址進行訪問（涉及到登錄驗證）；
其他用戶登錄時，輸入這個網址（涉及到權限控制）
構造ID和EmployeeID為SQL注入的參數，然后訪問（涉及到SQL注入）
以及稍后會涉及到的XSS、Session、Cookie等場景。
?
五.XSS
跨站腳本攻擊（Cross Site Scripting），為了和層疊樣式表css區分，簡寫為XSS。
1.原理
攻擊者在網頁中嵌入客戶端腳本(例如JavaScript), 當用戶瀏覽此網頁時，腳本就會在用戶的瀏覽器上執行，從而達到攻擊者的目的。
例：
存在一個文本控件，其中value1from來自用戶的輸入： <input type="text" name="address1" value="value1from">直接輸入 "/><script>alert(document.cookie)</script><!-，那么實際執行的語句：
<input type="text" name="address1" value=""/><script>alert(document.cookie)</script><!- ">也可以將內容放到URL中進行訪問：
http://localhost:10344/AbnormalPunch/ApplySubmit?ID=<script>alert(document.cookie)</script>
我們可以看到，輸入的內容直接改變了程序的執行代碼，導致程序執行結果為攻擊者想要的。
2.類型：???
反射型XSS：需要欺騙用戶進行操作才能觸發XSS代碼，主要威脅個體用戶
持久性XSS：代碼儲存在服務器中，用戶訪問時即可直接觸發XSS代碼，威脅大量用戶
3.解決思路：對數據進行html編碼處理，保證用戶輸入的數據不會改變程序代碼
?將重要的cookie標記為http? only,這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了.
只允許用戶輸入我們期望的數據。 例如： 年齡的textbox中，只允許用戶輸入數字。 而數字之外的字符都過濾掉。
過濾或移除特殊的Html標簽， 例如: <script>, <iframe> ,? < for <, > for >, " for
過濾JavaScript 事件的標簽。
4.XSS漏洞的測試：
A.查看代碼，驗證變量是否經過html編碼處理
B.準備測試腳本：
"/><script>alert(document.cookie)</script><!--
<script>alert(document.cookie)</script><!--
"οnclick="alert(document.cookie)
遍歷TextBox或者其他文本控件，輸入這些測試腳本，如果瀏覽器彈出窗口且窗口內容為cookie，證明存在XSS漏洞。
C.使用掃描工具如appscan
D.自行設計自動化測試腳本，用HttpWebRequest類，把包含xss 測試腳本發送給Web服務器，然后查看HttpWebResponse中，我們的XSS測試腳本是否已經注入進去了。
5.其他：
目前主流瀏覽器如Chrome、FireFox、IE8以上版本等都加入了安全機制用來過濾XSS；
ASP.NET中有防范XSS的機制，對提交的表單會自動檢查是否存在XSS，當用戶試圖輸入XSS代碼的時候，ASP.NET會拋出一個錯誤，暫時不清楚其他語言是否有這種機制。
?
六.CSRF
跨站請求偽造（Cross-Site Request Forgery），也被稱為“One Click Attack”或者Session Riding，簡寫為CSRF或XSRF。。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，并且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。
1.CSRF的原理：CSRF可以理解為攻擊者盜用了你的身份，以你的名義發送惡意請求，具體步驟如下：
1). 用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登錄網站A；
2).在用戶信息通過驗證后，網站A產生Cookie信息并返回給瀏覽器，此時用戶登錄網站A成功，可以正常發送請求到網站A；
3). 用戶未退出網站A之前，在同一瀏覽器中，打開一個TAB頁訪問網站B；
4). 網站B接收到用戶請求后，返回一些攻擊性代碼，并發出一個請求要求訪問第三方站點A；
5). 瀏覽器在接收到這些攻擊性代碼后，根據網站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網站A發出請求。網站A并不知道該請求其實是由B發起的，所以會根據用戶C的Cookie信息以C的權限處理該請求，導致來自網站B的惡意代碼被執行。
?
?
因此，對于一個用戶來說，完成給CSRF攻擊必須要兩個步驟：
A.登錄受信任網站A，并在本地生成Cookie。
B 在不登出A的情況下，訪問危險網站B。
2.解決思路：
A.驗證 HTTP Referer 字段：
在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自于同一個網站；因此只需要驗證Referer的域名，驗證合法后再進行下一步操作。
然而，Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對Referer的具體實現可能有差別，并不能保證瀏覽器自身沒有安全漏洞。對于某些瀏覽器，比如 IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值。
B.在請求地址中添加 token 并驗證：
要抵御 CSRF，關鍵在于在請求中放入黑客所不能偽造的信息，并且該信息不存在于cookie 之中。可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token，并在服務器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。
C. 在 HTTP 頭中自定義屬性并驗證:
把它放到 HTTP 頭中自定義的屬性里。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，并把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心 token 會透過 Referer 泄露到其他網站中去。
把它放到 HTTP 頭中自定義的屬性里。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，并把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心 token 會透過 Referer 泄露到其他網站中去。
3.CSRF漏洞的測試：
A. 最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段后再重新提交，如果該提交還有效，那么基本上可以確定存在CSRF漏洞。
B.使用相關工具進行測試：CSRFTester，CSRF Request Builder等；原理使用CSRFTester進行測試時，首先需要抓取我們在瀏覽器中訪問過的所有鏈接以及所有的表單等信息，然后通過在CSRFTester中修改相應的表單等信息，重新提交，這相當于一次偽造客戶端請求。如果修改后的測試請求成功被網站服務器接受，則說明存在CSRF漏洞，當然此款工具也可以被用來進行CSRF攻擊。
?
七.?URL跳轉漏洞
1.實現原理：
服務端未對傳入的跳轉URL變量進行檢查和控制，可能導致可惡意構造任意一個惡意地址，誘導用戶跳轉到惡意網站。
一般來說，URL跳轉的測試方法為修改參數中的合法URL為非法URL，然后查看是否能正常跳轉或者響應包是否包含了任意的構造URL。
2.測試方法：
修改參數中的合法URL為非法URL，然后查看是否能正常跳轉或者響應包是否包含了任意的構造URL?
?
八.其他安全角度的考量
1.安裝包測試：對C/S端的程序，安裝包主要考慮反編譯、簽名、完整性、權限等
2.數據庫：對于數據庫中的敏感字段，如用戶名、密碼等應該進行加密處理后再存儲；Cookie等敏感信息也要考慮設置過期時間等；
3.日志、配置文件中盡量不要包含敏感信息
4.賬戶安全：數據庫中的密碼加密存儲，傳輸的密碼加密，密碼多次輸入錯誤后進行鎖定，多設備登錄的處理、注銷后的身份驗證等
5.結合實際版本需要的考量：比如一款電商APP，提交訂單接口時傳入了訂單信息和訂單總金額，支付接口根據提交訂單接口傳入的總金額進行支付；問題在于支付接口完全信任了訂單金額沒有做驗證，那么可以直接調用訂單接口偽造金額從而以便宜的價格購物。
?
轉載自：https://www.cnblogs.com/rd-ddddd/p/7718206.html
?
?
轉載于:https://www.cnblogs.com/fqfanqi/p/11032544.html
總結
以上是生活随笔為你收集整理的安全测试基础 -- 概述【转载】的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： elementui el-table根据
- 下一篇： 记录一次redis事故