軟件測試中web威脅類型學習筆記
安全測試檢查系統對非法侵入的防范能力。安全測試期間,測試人員假扮非法入侵者,采用各種辦法試圖突破防線。例如,①想方設法截取或破譯口令;②專門定做軟件破壞系統的保護機制;③故意導致系統失敗,企圖趁恢復之機非法進入;④試圖通過瀏覽非保密數據,推導所需信息,等等。理論上講,只要有足夠的時間和資源,沒有不可進入的系統。因此系統安全設計的準則是,使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
安全測試用來驗證集成在系統內的保護機制是否能夠在實際中保護系統不受到非法的侵入。俗話說: “ 系統的安全當然必須能夠經受住正面的攻擊 —但是它也必須能夠經受住側面的和背后的攻擊。 ”
在安全測試過程中,測試者扮演著一個試圖攻擊系統的個人角色。測試者可以嘗試去通過外部的手段來獲取系統的密碼,可以使用可以瓦解任何防守的客戶軟件來攻擊系統;可以把系統“制服”,使得別人無法訪問;可以有目的地引發系統錯誤,期望在系統恢復過程中侵入系統;可以通過瀏覽非保密的數據,從中找到進入系統的鑰匙等等!
只要有足夠的時間和資源,好的安全測試就一定能夠最終侵入一個系統。系統設計者的任務就是要把系統設計為想要攻破系統而付出的代價大于攻破系統之后得到的信息的價值。
做安全測試,首先要了解所測的那些漏洞的形成原理,學習并筆記之。
1.孤立資源泄漏
孤立資源——在整個web應用中沒有一個鏈接直接指向該資源,但卻在該應用范圍內存在,通過某URL請求可以直接訪問到。如下圖例子,很顯然暴露了站點的數據庫結構!
web應用在良好的編碼風格和雷同架構下,會出現很多相似的地方。見名知義給了開發者們便利,也一樣給了攻擊者便利。誰都知道test可能是一個測試頁面,logs目錄下可能是一些日志文件,于是攻擊者也知道這個規律,窮盡所有猜測就可以形成字典,即使這個字典不夠完整,可以利用模式匹配。
2.參數操縱
Web應用程序總是需要用戶交互,需要用戶提供一些數據。攻擊者則總是會提供一些超出期望的數據,讓web應用程序拋異常。雖然大多web站點都不會出現將包含了內部信息的錯誤報告到瀏覽器。但這并沒有解決根本的問題,Web應用仍然存在安全威脅。
如SQL盲注。如果/xxx.jsp?id=1與/xxx.jsp?id=1 and 1=1的返回結果沒有差別,而/xxx.jsp?id=1 and 1=2則返回報錯,那么這里很有可能存在SQL Injection漏洞,進一步,使用(以mysql數據庫為例)/xxx.jsp?id=1 and (select SUBSTRING((select user from mysql.user limit 1),1,1))=’a',可以破解出一個數據庫用戶名。
XPath注入,如同針對數據庫的SQL注入,XPath就是針對XML文檔的注入,只是XML中只有字符串。如上面的例子,如果請求訪問的是XML文檔,則嘗試/xxx.jsp?id=1′ and ‘1′=’1′。
文件提取,核心的思路是利用了操作系統的父路徑——“..”,通過一級級訪問上級目錄從而訪問到web范圍以外服務器操作系統中的其他文件。
XSS,有Reflected XSS,一般表現為攻擊者構造包含XSS的URL,再利用一些社會工程學手段騙得受害者點擊。有Stored XSS,如果包含XSS的代碼被存入了網站數據庫中,而且,頁面查詢顯示這筆數據時沒有做過額外的處理,那么只要瀏覽這張頁面,就會遭到攻擊。有DOM-based XSS,類似Reflect XSS,不同的是由應用程序客戶端已有的腳本來實現,比如url為/xxx.jsp?name=yyy的請求,在回轉的頁面中,直接用JavaS
會話劫持,是指攻擊者以某種形式獲得他人的session id,并以他人身份訪問資源。
3.其他
CSRF,簡單來說,正常登錄的用戶訪問A站點,訪問到某個鏈接,而這個鏈接所指向的頁面,先構造好A站點某個表單的請求,接著提交請求,最后locate到A站點或其他地方,在正常用戶看來,只是做了一個頁面跳轉,而在期間,他不自知的提交了某個表單的請求,比如發了一條垃圾評論(很可能包含了攻擊者的那個特別鏈接)。之所以稱為跨站,是因為偽造的請求在另一個完全不搭界的站點上完成。
Phishing,說白了就是網站偽造欺詐,從而簡單的獲得用戶的個人信息。
DoS,一句話,惡意請求的數量過多,導致正常請求不能處理而被拒絕。
為了更好的解決問題,首先要了解問題的本質。到目前,有些問題已經比較明晰,有些問題還有待深入研究,我將繼續fighting!
文中例子或山寨描述,都屬自己的理解,如有錯誤,請批評指正!謝謝^_^
文章來源于領測軟件測試網 http://www.k11sc111.com/