安全測試

時間 2019-11-09

原文原文鏈接

本來：http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safety-testphp

安全測試是在IT軟件產品的生命週期中，特別是產品開發基本完成到發佈階段，對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的過程。html

安全測試和普通測試的類似性

簡單來講，安全測試其實就是一個發現軟件安全漏洞的過程，旨在保護軟件系統的數據與功能。它跟常規測試類似的地方至少有如下幾點：前端

No.	Summary	Details
1	目標相似	預防、檢測系統的缺陷（儘早、頻繁反饋系統質量信息）
2	在軟件生命週期中的工做過程相似（以敏捷團隊爲例）	－瞭解系統業務需求－針對業務與系統功能設計用例－與其餘角色一塊兒啓動需求的開發－與其餘角色一塊兒在開發環境驗收需求－在測試環境進行全面測試－分析並總結測試結果－反饋測試結果
3	測試用例有不少重合	面向用戶的測試場景很是相似
4	都須要有探索的過程	對會對不一樣的業務場景有目的的進行探索
5	都要有測試人員必備的「懷疑態度」	對開發人員的代碼保持友好而警戒的態度

1. 目標相似

無論是常規測試仍是安全測試，都有一個原則：預防勝於檢測。這個比較容易理解，無論是常規測試的缺陷也好，仍是安全測試的漏洞也好，若是能預防使它不發生，就省了後期的修復與驗證工做。若是不能成功的預防缺陷，能早一些發現的話，確定比晚發現的修復的成本低。html5

2. 在軟件生命週期中的過程相似

以敏捷開發團隊爲例，常規測試人員在各個階段的事情，安全測試人員也要作：mysql

瞭解業務的需求，以免混亂的測試優先級；
針對業務與系統功能設計用例：常規測試須要關注系統功能，安全測試一樣也不能脫離系統功能；
與其餘角色一塊兒啓動需求的開發：溝通測試用例，避免由於溝通不足形成返工；
與其餘角色一塊兒在開發環境驗收需求：儘早提供反饋，發現缺陷了開發能夠立刻修正
在測試環境進行全面測試：針對端到端的場景進行測試，儘量把第三方系統（若是有的話）也包括進來；
分析並總結測試結果：整理問題清單，排列優先級；
反饋測試結果：把測試結果反饋給團隊等干係人。

3. 測試用例不少重合

在面向終端用戶的測試場景上，常規測試的用例與安全測試的用例是很是相似的。好比對於登陸系統的功能，無論是常規測試仍是安全測試，咱們都會測試用戶輸入正確的用戶名是否能夠登陸，輸入錯誤的用戶名或密碼是否系統會如何反應。
好比我曾經工做的一個蒐集報稅人信息的系統，無論是常規測試仍是安全測試，常規測試會測試系統的登陸，系統信息的錄入與編輯，文件的上傳等等，安全測試也會測試這些業務場景。
由於在每個終端用戶能夠操做的場景上，均可能會有安全漏洞存在。因此，有了常規測試的經驗，咱們就至關於有了很多安全測試用例的儲備。linux

4. 都須要有探索的過程

測試是一個瞭解軟件系統是否完成咱們預期的過程，也是探索系統還有哪些咱們沒有預期的行爲的過程。安全測試的過程須要把探索的目標轉向安全漏洞。當咱們這麼作時，咱們一樣會獲得不少探索的樂趣。git

5. 都要有測試人員必備的「懷疑態度」

相信我們測試人員都很是熟悉一個場景－－開發人員說：「我只作了一個很小的代碼改動。」而後咱們帶着友好而警戒的態度，發現這個「很小的改動」引起了很大的問題。無論是在安全測試仍是非安全測試，這個警戒性是咱們都須要保持的良好傳統。
那麼，有了這麼多相似的地方，還缺什麼呢？若是想要作專家，還差不少。可是若是想立刻安全測試上起步，咱們能夠先作下面的改變。程序員

安全測試的三步曲

第一，轉換視角github

在我看來，無論是帶着全棧的經驗，仍是隻有部分技術知識，想要作好安全測試必須先轉換咱們觀察軟件的視角。舉個例子，讓咱們看看下這幅畫：web

一樣一幅畫，有人一眼看過去看到的是兩我的臉，而有人看到的是一個花瓶。這就是觀察的視角不一樣形成的。
在我剛開始接觸安全測試時就很深的體會到了這一點。當時我在測試一個Web應用的用戶登陸功能。當我輸入錯誤的用戶名來試着登錄時，瀏覽器上的提示信息爲「該用戶名不存在」。當我嘗試正確的用戶名而錯誤的密碼時，提示信息變成「密碼輸入錯誤。」對於這個清晰的錯誤提示我很是滿意。試想我如果一個真實的終端用戶，這個信息有效的幫助我縮小我所要糾錯的範圍，提升效率，很是好。
但是，就在我身邊坐着的安全測試人員立刻跳了出來：「這個提示信息須要改！敏感信息暴露了！」看着我一臉茫然，這位安全測試人員告訴我，經過咱們的提示信息，惡意的系統使用者能夠推測出哪些用戶名已經存在於系統中，而後利用這些用戶名能夠再進行密碼的暴力破解，縮小破解的範圍。因此，這個信息雖然爲合法用戶提供了便利，也爲不懷好意的系統使用者提供了便利。而每每這種便利爲惡意的系統使用者帶來的好處遠大於給合法用戶帶來的好處。
這個經歷讓我受震動的同時，也意識到之前可能不少安全漏洞已經擺在個人面前，我卻沒有看出來，由於我把它們過濾了。事實證實，在後來經歷的不一樣項目中，而當我轉換了視角，有些安全漏洞不須要我去找，而是本身跑到我眼前來的。真是得來全不費功夫。

第二，改變測試中模擬的對象

爲了能以不一樣的視角來觀察軟件，咱們必須改變咱們所模擬的對象。這也是一個讓咱們刻意練習轉換視角的有效方法。
咱們在作非安全測試的時候一般把本身想象成一個合法用戶，而後開始驗證系統是否能完成預設的目標。好比對於一個網上商城，咱們會驗證系統是否能讓用戶完成商品的瀏覽與購買，咱們也會測試一些異常的行爲，好比購買的商品數量不是數字而是一串無心義的字母時，目的是看系統是否能比較優雅的作出迴應。咱們這麼測試的目的每每是爲了確保用戶誤操做之後還可以繼續他們的購買，或者說不要給系統形成什麼嚴重的傷害。
若是要作安全測試，咱們則必須去模擬系統的另外一類使用者－惡意用戶。他們的目的是爲了尋找系統中可鑽的漏洞。好比一樣是一個網上商城，惡意用戶的目標之一就是要想辦法以較少的錢，甚至不付錢就能拿到商品。因此，若是惡意用戶進行了「誤操做」，他們不會停留在「誤操做」，而是經過「誤操做」來看系統是否給本身提供更多的線索。
因此，咱們轉換咱們測試時所模擬的對象，把思惟從一個合法用戶的視角中拉出來，轉換成一個惡意用戶。這須要一點時間，就如同以前看到的畫，若是咱們一開始看到的是人臉，要想下一次第一眼看到的是花瓶，咱們須要時間來刻意練習。

第三，使用專用的測試工具

有了思惟的轉換，咱們能夠加入新的測試想法。可是，在具體作安全測試的時候咱們會發現並非那麼容易去模擬惡意用戶的行爲。畢竟系統的前端會給咱們不少的屏障。並且惡意用戶可不總都是從系統前門進去的。這時候，使用一些工具，好比OWASP Zap(https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)、Burp(https://portswigger.net/burp/)等是很是有幫助的。咱們能夠在系統界面上執行功能測試的用例，用這些工具來獲取http請求，篡改後發送給後臺服務器。有了這些實用又比較容易上手的工具，咱們就能夠執行不少惡意用戶的操做場景了。
能作到這三點，起步就基本夠用了。

舉個例子吧

下面讓咱們以網上商城的買家在商品評價中上傳圖片這個功能來說講如何實踐這「三板斧」。假設咱們從項目初期就加入了，那麼咱們大體有七件事情要作：

識別系統中有價值的數據；
在需求分析階段加入惡意用戶需求；
針對惡意用戶需求設計測試用例；
參與啓動惡意需求的開發；
在開發環境驗收惡意需求的實現；
在測試環境中進行安全測試；
向團隊反饋所發現的安全漏洞。

不要擔憂，這不是7個全新的事情。這只是在每一個須要測試人員出現的地方增長了安全的工做而已。

1. 識別系統中有價值的數據

不少人認爲執行測試纔是測試，而咱們的安全測試從這裏就開始了。
瞭解了業務之後，咱們須要考慮系統中會有什麼有價值的數據。這是爲下一步加入惡意用戶需求作準備。對於一個網上商城，有價值的數據能夠包括產品信息、訂單信息、用戶信息、支付，等等。
這個環節對咱們測試人員來講並無太多額外的工做，畢竟咱們作非安全測試的時候也是須要了解業務。不過要注意了，咱們要測試的「圖片上傳功能」是一個涉及有價值數據的功能。咱們須要提升警戒了。

2. 在需求階段加入惡意用戶需求

惡意用戶需求是用來記錄惡意用戶想要在系統中達到的目的。與普通用戶需求的區別是，咱們不是要去實現它，而是使用它幫來助咱們遠離對系統使用者「不恰當的信任」。一般咱們須要針對每個合法用戶需求來增長一個或多個相對應的惡意用戶需求。
舉個例子，若是咱們這個「圖片上傳功能」的合法用戶需求爲：
做爲一個買家，我想在對商品進行評價的時候上傳圖片做爲買家秀，以便於參加返現營銷活動。
那麼對應的惡意用戶需求能夠是：
做爲一個惡意用戶，我想破壞買家秀返現活動，以便破壞商城的營銷活動。
「破壞買家秀返現活動」是一個大的目標。爲了設計用例方便，它能夠被細分爲一系列小目標。好比：

讓用戶沒法上傳圖片
讓頁面沒法正確顯示圖片
等等

有了惡意用戶需求的主幹信息，咱們就能夠開始下一步設計安全測試用例了。

3. 針對「惡意用戶需求」設計測試用例

如今咱們須要作的是努力把本身限制在「惡意用戶」的角度作頭腦風暴：「到底有什麼方法可使買家沒法上傳圖片信息呢？」，「讓頁面沒法正確顯示買家秀圖片又怎麼作到？」嗯，也許最直接的辦法就是讓服務器所在的機房斷電、斷網之類的。這是些不錯的想法，雖然執行難度有點大。不要緊，記錄下來。除此以外，咱們還能夠有其餘測試用例，好比：

使存儲圖片的磁盤空間被佔滿而沒法接受新的圖片；
使處理上傳圖片的進程繁忙而沒法接受新的上傳任務；
上傳特別大的圖片使用戶的客戶端須要很長時間才能下載完
上傳假裝成圖片的惡意代碼，進一步獲取服務器權限，刪除全部的買家秀圖片；
等等

若是這個時候想到新的測試用例也一樣記錄下來，好比「我想不購買也上傳買家秀圖片以得到返現」之類的。
不用太擔憂這個階段的測試用例過於「瘋狂」或者不夠完整，畢竟咱們對於系統的實現還不是很瞭解。咱們會在接下來的環節中完善具體的步驟。

4. 參與啓動惡意需求的開發（evil story kickoff）

在開發人員開始開發合法用戶需求以前，咱們須要跟業務分析人員、開發人員一塊兒溝通需求的內容。在敏捷軟件開發項目中咱們叫它story kickoff，即用戶故事啓動。當有了對應的惡意用戶需求時，咱們必然也要把它也加到啓動的範圍裏。目的是把咱們頭腦風暴出來的測試用例跟全部的角色來溝通。預防勝於檢測。

5. 在開發環境驗收惡意需求的實現

100%預防軟件的缺陷與漏洞是不太可能的，因此這個環節的存在是爲了提前反饋。
我曾經經歷過一個項目，都快上線了才決定作安全測試，結果測出來的問題之一是用戶會話（user session）不能正確過時的問題，通過一番研究，發現須要對系統設計的架構進行比較大的修改，只能作個臨時的修復讓系統先上線，而後再把系統的架構給改了，重寫這部分功能，從新測試。代價很是高。因此無論是安全測試仍是非安全測試，」在開發環境驗收惡意需求的實現「這個步驟都不能缺乏。
而這個環節存在的第二個目的是讓咱們能夠從開發人員那裏獲得支持－具體實施的細節，幫助咱們完善具體的測試用例。好比在這個時間點咱們若從開發人員那裏得知系統的後臺沒有對圖片上傳者作身份驗證，咱們就能夠至少增長一個測試的用例：「惡意用戶以其餘用戶的身份上傳一個風馬牛不相及的圖片」。有時候錯誤的圖片比沒有圖片更具備殺傷力。

6. 在測試環境中進行安全測試

終於到了運行測試的階段。可能這個時候咱們以前想到的測試用例已經被開發人員給解決。若是是這樣那就太好了。可是，事實並不是有這麼美好。第一，可能這些用例只是在開發環境上成功經過了，可是在理想的測試環境裏，也就是類產品環境裏，這些用例可能並不能徹底經過；第二，確定還有其餘須要探索的地方。這時咱們就能夠用OWASP Zap、Burp這樣的工具來輔助咱們把以前的安全測試用例執行一次，同時還再能夠對系統的安全性作一下探索測試。

7. 向團隊反饋所發現的安全漏洞

都測得差很少的時候，咱們就能夠向團隊以及相關干係人彙報安全測試的結果了。跟非安全測試不一樣的地方是，當咱們反饋安全漏洞的時候，要考慮是否不一樣漏洞結合起來會增長系統的安全風險。舉個例子：若是有兩個安全漏洞，一個是系統沒有很強的用戶帳戶密碼規規則，另外一個是系統沒有對上傳圖片的大小作限制，那麼惡意

用戶把這兩個漏洞一結合起來，事情就比原來風險大不少。那麼咱們就必須建議提升這兩個漏洞中任意一個的優先級。

當咱們用「三板斧」走完這七步之後，咱們已經能夠把不少安全漏洞都挖出來了。是否是沒有想象中的難？因此，測試同仁們，讓咱們作安全測試吧！

第二部分

做者：Twosecurity
連接：https://www.zhihu.com/question/21606800/answer/219614097
來源：知乎
著做權歸做者全部，轉載請聯繫做者得到受權。

早期的互聯網很是的單調，通常只有靜態頁面，如今，隨着技術的發展，web上大多數站點其實是web應用程序，在服務器和瀏覽器之間進行雙向的信息傳遞。他們支持註冊登陸，金融交易，搜索及用戶創做的內容。用戶只須要擁有一個瀏覽器，就能實現各類功能。

Web 是指一個網站的前端頁面到後端服務，好比咱們常見的 Javascript、PHP、Python、Mysql、jQuery、Docker 等，包括開發、運維這些服務。

因此在我看來 Web 安全也就是從安全的角度探索 Web 的一種方式。

爲了可以更簡單的理解一些常見漏洞，咱們首先來看一下這份試卷：

試卷 考生姓名：__________
考生學號：__________

1、詩歌補寫
牀前沒月光，___________。
春眠不覺曉，___________。

2、數學運算（在括號內填入數字）
3 500 +400 * 3 / 2 + 1 = （）
4 ( 1 + 2) / 3 * 400 +500 = （）

考生姓名：__________

考生學號：__________

首先咱們來看這個，試卷的名字和編號填寫，這個部分有「漏洞」嗎？有

學生的姓名和編號都寫在這兒，沒有作任何保護措施，所以，你只要偷看了某人的試卷上的這部份內容，而後把你的試卷的上的姓名和考生編碼寫成和他同樣的便可假裝出他的身份。

漏洞攻擊成功

1、詩歌補寫
牀前沒月光，___________。
春眠不覺曉，___________。

這道題有漏洞嗎？有

這道題的答案原本應該是「疑似地上霜」和「到處聞啼鳥」

But，問題中，並無規定答案裏不能添加標點符號，因此，我徹底能夠把「疑是地上霜，舉頭望明月，低頭思故鄉」以及「到處聞啼鳥，夜來風雨聲，花落知多少」當作答案寫進去。

漏洞再次進攻成功：P

2、數學運算（在括號內填入數字）

3 500 +400 * 3 / 2 + 1 = （）

4 ( 1 + 2) / 3 * 400 +500 = （）

這個問題有漏洞嗎？有

出題者規定了只能填入數字，但卻沒有說是什麼數字，也沒有規定多少位，那麼個人答案能夠是
中文數字「壹佰壹拾圓」、羅馬數字「MCI」或「0000000000001101」。

漏洞第三次進攻成功 XXD

這份試卷簡單的模擬了Web漏洞的攻擊思想，在實際中，咱們打開一個網頁提交登陸或者是搜索都會通過服務器作的一系列處理又回到瀏覽器，在這個過程當中咱們提交的數據會被帶入到一系列的填空題中，有的是咱們能猜到的，有的則是意想不到的，有的會通過SQL查詢進行填空，有的會被帶入到命令行中進行執行，最後又把結果返回給瀏覽器進行填空，也就是最後咱們看到的結果。

在數據的傳輸中，咱們能夠把 web 簡單的分爲幾個層次：

瀏覽器：瀏覽器即客戶端，提供客戶端和服務器端的數據信息交互。
http：客戶端與web服務器進行交互時就存在web請求，這種請求都基於統一的應用層協議——HTTP協議來交互數據。http屬於輕量級協議，無需鏈接，提供了對通訊錯誤的容錯性。
中間件：中間件是位於平臺（硬件和操做系統）和應用之間的通用服務
Server容器：Server容器負責解析用戶請求和腳本語言，相似的有Tomcat，JBoss等。咱們訪問網頁看到是web容器處理後的內容。
數據庫：動態頁面可提供交互式的信息查詢服務，主要依賴於web數據庫的實現，對外提供包含表單的Web頁面做爲訪問接口，查詢結果也以包含數據列表的Web頁面形式返回給用戶。

固然除了這些數據也有可能流向不些不可見的第三方服務商。

下圖就展現了數據的傳輸流程，以及不一樣階段常常出現的漏洞及其緣由:

咱們常見的Web漏洞類型主要有SQL注入、XSS、遠程命令執行以及越權等。如下咱們分別用舉例的形式爲你們介紹這幾種漏洞。

（SQL注入）

所謂SQL注入，就是經過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。

select * from username = ____ and password=_____
select * from username "test" or ""="" and password="123456"

（XSS）

XSS則是攻擊者往Web頁面裏插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入Web裏面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。

<p style='color:red'>你好啊，尊敬的______<p>
<p style='color:red'>你好啊，尊敬的 xxx<script>alert(1)</script><p>

(遠程命令執行)

而遠程命令執行，是用戶經過瀏覽器提交執行命令，因爲服務器端沒有針對執行函數作過濾，致使執行命令。

ping _______
ping www.baidu.com & wget xxxxxxxxxxx

（越權）

越權漏洞是比較常見的漏洞類型，越權漏洞能夠理解爲，一個正常的用戶A一般只可以對本身的一些信息進行增刪改查，可是因爲程序員的一時疏忽，對信息進行增刪改查的時候沒有進行一個判斷，判斷所須要操做的信息是否屬於對應的用戶，能夠致使用戶A能夠操做其餘人的信息。

Cookie: uid=11426;
Cookie: uid=1;

關於越權，就像咱們剛剛試卷體中的姓名部分。

再展現一個數據的傳輸流程圖，以便直觀清晰的看到，數據在各層中是怎樣運做的，以及可能發生的漏洞：

瞭解了這幾個漏洞以後咱們能夠看到原理都有些相似，也很簡單，固然咱們只要再也不侷限於概念名詞就會發現 web 安全的大部分漏洞都很簡單。更多時候，發現一個複雜的漏洞須要是隻是耐心。

概念，不是一個神聖的東西，概念不少時候只是bullshit。不少概念的產生是由於須要認識和歸納某種存在着的現象而不得已產生的，概念也許是必須的但並非必然如此的。

換句話說，概念僅能夠被看作是一種努力嘗試描述後的結果之一。或者也能夠說概念是提出這個概念的人自嗨的產物，跟其餘人關係不大。甚至，有些概念是‘別有用心’的發明來合理化某種其實沒必要合理化可是存在的現象。

因此不要把本身拘泥於一個這樣的概念中來思考所面臨問題的實質。把概念忘了，你纔可能看清楚你和事物自己的關係。

徹底沒有基礎我該從哪下手？

徹底沒有基礎學習 Web 安全是件比較難的事情，因此我給出的最小的方案和最少的建議。

工具

先用 AWVS 掃幾個測試網站大致瞭解一下

把掃到的漏洞復現，瞭解怎麼利用，主要了解：

XSS
SQL 注入
遠程代碼執行

開發

書籍

《細說 PHP》

實踐

使用 PHP 寫一個列目錄的腳本，能夠經過參數列出任意目錄的列表
使用 PHP 抓取一個網頁的內容並輸出
使用 PHP 抓取一個網頁的內容並寫入到Mysql數據庫再輸出

安全

實踐

手工找 http://testphp.vulnweb.com/ 的漏洞，對比 AWVS 的結果

書籍

《黑客攻防---web安全實戰詳解》
《安全之路：Web滲透技術及實戰案例解析（第2版）》
仍是看不懂就找本身能看得進的 Web 安全的書

探索資源，我在研究和學習的過程當中更加好的資源和工具來幫助咱們成長和解決問題？

平時咱們安裝一個mysql，要先處處找安裝包，再一步步配置，運行，還不知道裝哪了。開機就自動啓動了，用了 docker 後再也沒這個煩惱拉，一行命令，或者是在Kitematic界面上點一下就運行拉。

Github https://www.github.com

搜索 awesome-xxx

找到大牛的 github 看 stars，也就是收藏的項目

https://github.com/flankerhqd?tab=stars 移動安全
https://github.com/orangetw?tab=stars WEB 安全、CTF
https://github.com/EtherDream?tab=stars 前端安全
https://github.com/l3m0n?tab=stars 滲透測試、內網安全
https://github.com/ring04h?tab=stars 安全開發

探索頻道 https://github.com/explore

主要是一些有趣的新潮的項目
固然也有安全相關的啦 https://github.com/showcases/security

趨勢 https://github.com/trending/developers
善用收藏

Docker hub https://hub.docker.com/ ，用於查找已經封裝好的環境，減小裝環境帶來的麻煩

舉例：

數據庫 Mysql https://hub.docker.com/_/mysql/
一句話安裝運行：docker run -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:latest
XSS攻擊平臺BeeF https://hub.docker.com/r/janes/beef/ 一句話安裝運行：docker run --rm -p 3000:3000 janes/beef
Kali 滲透測試 Linux 系統 https://hub.docker.com/r/kalilinux/kali-linux-docker/
漏洞靶場 https://hub.docker.com/r/citizenstig/dvwa/ 一句話安裝運行：docker run -d -p 80:80 citizenstig/dvwa
Nmap https://hub.docker.com/r/uzyexe/nmap/
一句話安裝運行：docker run --rm uzyexe/nmap -p 80 http://example.com
搜索通用漏洞靶場，關鍵字：cve-
安全相關的 Paper