網(wǎng)站類安全測試流程規(guī)范

網(wǎng)站類安全測試指導(dǎo)文檔34/34網(wǎng)站類安全測試流程規(guī)范說明：本文僅適用于：國際站、中文站和國際交易站

目錄1. 安全測試流程規(guī)范 41.1定義 41.2角色和職責(zé) 41.3流程圖 51.4安全測試必要性的評估 61.5任務(wù)描述 71.6自動化安全測試錄制場景設(shè)計指導(dǎo)方法 101.7手工測試方法 101.8安全測試手工測試用例規(guī)范 101.9記錄安全漏洞的規(guī)范性 111.10主要產(chǎn)出物 111.11注意點說明 112. Web安全漏洞簡介及測試說明 122.1XSS(CrossSiteScript) 132.2CSRF(Cross-siteRequestForgery) 142.3SQLInjection 152.4URLRedirect 162.5AccessControl 162.6上傳下載文件 182.7Flash安全 193. 自動化工具Hatirx介紹 203.1自動化工具Hatirx 203.2Hatirx工具使用 203.3報表中信息 233.4手動測試工具 233.5安全工具的原理 233.6漏洞特征代碼庫在哪里？ 243.7Hatrix工具注意事項 244. 安全測試分析舉例 24

安全測試流程規(guī)范定義此文檔的主要作用是對測試工程師在測試過程中的安全測試進(jìn)行指導(dǎo)。安全測試過程包括測試工程師對安全測試范圍的界定、安全工程師的代碼安全審核、測試工程師驗證及測試。測試工程師目前主要采用兩種方法做安全測試，一種是采用自動化安全工具Hatrix掃描測試，自動化安全工具主要能夠覆蓋XSS、CSRF、SQLInjection，一種是對URLRedirect和Accesscontrol這兩種漏洞采用手工方式進(jìn)行測試驗證，兩者的區(qū)別主要就是針對的漏洞類型不同。安全審核和安全測試區(qū)別在于：安全審核屬于白盒測試，而安全測試屬于黑盒測試，兩者并不能互相取代。兩者的目的是一致的，為了保證代碼的安全性。但安全測試采用的是黑盒測試方案，而安全審核是采用靜態(tài)代碼掃描的方案，不考慮應(yīng)用的邏輯，僅僅關(guān)心代碼本身的安全特性。并且只覆蓋XSS，CSRF和SQLInjection三種漏洞，同時安全審核檢測出的只是可疑點，不一定就是漏洞，是否是漏洞需要開發(fā)自己確定。所以安全審核的局限在于2點，1：無法覆蓋URLRedirect和Accesscontrol漏洞。2：無法最終確認(rèn)漏洞。安全測試正好能夠禰補安全審核的局限。角色和職責(zé)序號角色職責(zé)(1)PM/技術(shù)經(jīng)理分配漏洞修復(fù)任務(wù)給研發(fā)工程師；提交達(dá)到提測要求的代碼版本給QA；(2)開發(fā)工程師在提交測試前進(jìn)行安全審核，并在代碼安全審核報告中登記信息；對漏洞進(jìn)行修復(fù)；對于需要defer的漏洞，跟安全工程師確認(rèn)，并輸入defer漏洞列表；(3)QA評估是否需要做安全測試，提交安全測試范圍（《xxx項目/小需求安全測試傳遞清單》）給產(chǎn)品線安全測試接口人或安全工程師Review；測試分析階段，將安全漏洞的測試方法加入到測試分析中；對提測版本的安全狀態(tài)進(jìn)行測試；將安全漏洞提bug到QC；對已修復(fù)漏洞進(jìn)行驗證；對QC中的安全bug進(jìn)行跟蹤；項目或小需求完成后，記錄安全漏洞數(shù)據(jù)，并將安全測試質(zhì)量報告（《安全測試傳遞清單》）郵件發(fā)出。(5)安全測試接口人幫助QA劃分安全測試范圍，輔助安全測試人員成長（前期需安全工程師協(xié)助）Review安全測試范圍（《xxx項目/小需求安全測試傳遞清單》）（前期需安全工程師協(xié)助）數(shù)據(jù)保存，由于安全權(quán)限控制嚴(yán)格，最后的《xxx項目/小需求安全測試傳遞清單》由安全測試接口人負(fù)責(zé)在SVN上保存。Svn地址：/repos/ali_QA/22_安全測試領(lǐng)域）(4)安全工程師提供必要的協(xié)助，以使開發(fā)工程師順利修復(fù)漏洞；幫助QA劃分安全測試范圍，輔助安全測試人員成長；對defer漏洞進(jìn)行確認(rèn)；流程圖項目中安全測試流程圖小需求中安全測試流程圖安全測試必要性的評估1、如何評估項目是否做安全測試：2011年要求項目均需要做安全測試，有特殊（如底層數(shù)據(jù)遷移等），需與安全工程師評估是否要做安全測試，并在《XXX項目安全測試傳遞清單》中注明。2、如何評估小需求是否做安全測試：Aone上安全測試評估選項（目前未集成）：說明：在Aone上未集成該安全測試評估選項時，暫且先用《小需求安全功能list模板》代替，在小需求提測前交給PM/技術(shù)經(jīng)理，PM/技術(shù)經(jīng)理進(jìn)行各選項評估，將該模板填好傳遞給QA，QA再根據(jù)選項判斷是否做安全測試。任務(wù)描述任務(wù)角色任務(wù)描述時間輸入輸出KickoffPMkickoff的時候，邀請安全工程師參加Kickoff，正式介入項目，了解項目背景及項目功能點和項目里程碑點。安全工程師理解FRD,對項目安全需求審核；視情況參加kickoff；（如不參加Kickoff安全工程師需要提前與PM溝通確認(rèn)好）；評審后的FRD安全需求分析報告（給開發(fā)同學(xué)的一些安全性建議）需求分析QA（現(xiàn)階段由安全工程師輔助完成）評審需求，識別哪些需求可以用腳本覆蓋測試；哪些需要測試工程師編寫用例形式，手工完成；需求分析《XXX項目/小需求安全測試傳遞清單》項目測試負(fù)責(zé)人協(xié)助測試工程師一起評估手工安全測試范圍；測試計劃里增加安全測試點的測試用例及執(zhí)行安全測試工作量、時間安排；手工安全測試執(zhí)行周期與功能測試周期保持一致。安全測試工具運行周期為第一輪功能測試，回歸測試之前；需求分析測試設(shè)計QA對項目進(jìn)行安全測試需求分析，對安全測試手工或自動化方法給出具體方案；自動化安全工具測試自動化安全工具掃描頁面；手工安全用例測試手工測試點；添加安全用例評審；測試設(shè)計和用例編寫QC上的安全測試策略測試用例評審測試工程師首先評審安全測試用例部分（評審前需要提前將用例發(fā)送給安全工程師預(yù)審）；安全工程師參與安全測試用例評審（帶著問題參加評審）；代碼安全review安全工程師開發(fā)提測前進(jìn)行安全審核（代碼安全review）：走Aone流程的直接于Aone上觸發(fā)進(jìn)行安全審核；不走Aone流程的提測前需提交給安全工程師進(jìn)行安全審核，并記錄安全審核結(jié)果報告；《XXX項目/小需求代碼安全審核報告》開發(fā)自測開發(fā)工程師 根據(jù)安全測試工具輸出的報告修復(fù)漏洞；編碼階段完成進(jìn)行安全審核，回歸測試前完成漏洞修復(fù)提交測試PM/技術(shù)經(jīng)理根據(jù)項目計劃，將代碼版本提交QA進(jìn)行測試；編碼階段至測試階段執(zhí)行安全測試QA自動化安全工具（Hatrix）測試進(jìn)入功能測試階段，錄制設(shè)計好的場景并掃描，如發(fā)現(xiàn)安全漏洞，根據(jù)錄制腳本在QC系統(tǒng)中提交安全類型的Bug，分配給相應(yīng)開發(fā)工程師，描述中需注明安全漏洞的個數(shù)，并上傳安全測試工具輸出報告作為附件；注：項目掃描輸出報表只需在QC平臺提交一個安全類型的bug；第一輪功能測試啟動時開始執(zhí)行，第一輪功能測試結(jié)束前輸出安全測試工具輸出報告QC上的安全Bug《XXX項目/小需求安全測試工具輸出報告》手工安全用例測試根據(jù)安全測試用例執(zhí)行，如發(fā)現(xiàn)安全漏洞，在QC系統(tǒng)中提交安全類型的Bug，分配給相應(yīng)功能開發(fā)人員，描述中需注明安全測試類型及操作步驟；驗證安全測試發(fā)現(xiàn)的缺陷；功能測試執(zhí)行全階段（包括第一輪測試，第一輪回歸測試、第二輪回歸測試）QC上的安全類型Bug分配開發(fā)工程師修復(fù)漏洞PM/技術(shù)經(jīng)理根據(jù)QA上傳的安全測試工具輸出報告，分派開發(fā)工程師對漏洞進(jìn)行修復(fù)，確認(rèn)漏洞全部修復(fù)或提交遺留問題給安全工程師審核；在QC安全類型bug中注釋漏洞修復(fù)情況；將defer漏洞列表提交給安全工程師確認(rèn)；若安全工程師不同意Defer，安排開發(fā)工程師修復(fù)漏洞或提請產(chǎn)品線經(jīng)理審批。并將審批意見通知給安全工程師；功能測試階段安全測試工具輸出報告漏洞修復(fù)結(jié)果Defer漏洞列表驗證安全漏洞修復(fù)情況QA再次運行安全測試工具及腳本，如果還有漏洞，將安全測試工具輸出報告再次作為附件上傳到QC的Bug中。bugreopen給相應(yīng)開發(fā)人員；如果沒有漏洞，將bugclose；安全漏洞處理完畢做為進(jìn)入回歸測試的條件；功能測試階段PM/技術(shù)經(jīng)理在QC安全類型bug中注釋的漏洞修復(fù)情況QC上的安全Bug《XXX項目/小需求安全測試工具輸出報告》確認(rèn)DeferredBug安全工程師審核安全測試報告；對PM/技術(shù)經(jīng)理提交的Deferred漏洞列表進(jìn)行確認(rèn)，確認(rèn)并達(dá)成一致意見后在QC相應(yīng)的bug上填寫Deferred備注；功能測試階段Defer漏洞列表QC上的安全BugDefer漏洞列表QA對安全工程師確認(rèn)的Deferred安全類缺陷列表進(jìn)行確認(rèn)，達(dá)成一致意見后在QC相應(yīng)的bug上填寫備注，并將QC上的bug設(shè)置為deferred狀態(tài)；功能測試階段Defer漏洞列表QC上的安全BugDefer漏洞列表結(jié)果記錄與備份QA將安全測試過程中的Bug和DeferredBug的記錄；總的Bug數(shù)的統(tǒng)計均更新于《XXX項目/小需求安全測試傳遞清單》并郵件發(fā)出?；貧w測試階段《XXX項目/小需求安全測試傳遞清單》《XXX項目/小需求安全測試傳遞清單》QA接口人將結(jié)果保存于SVN上，SVN地址：/repos/ali_QA/22_安全測試領(lǐng)域）《XXX項目/小需求安全測試傳遞清單》《XXX項目/小需求安全測試傳遞清單》自動化安全測試錄制場景設(shè)計指導(dǎo)方法Hatitx腳本錄制的覆蓋面要求覆蓋UC中涉及的所有請求的頁面。請求包括了get和post請求，主要是頁面中的鏈接和表單提交。錄制場景的設(shè)計可以按照功能、業(yè)務(wù)邏輯進(jìn)行等價類劃分，

例如：可以按照會員類型劃分等價類，UC中沒有顯示說明會員類型不同會引起業(yè)務(wù)或展示頁面邏輯不同，那么只需要錄制一遍，但是UC中說明了不同會員類型的業(yè)務(wù)邏輯不同，即使同樣的請求或是表單提交都需要分別錄制。一個場景從業(yè)務(wù)起始頁面開始包含等價類劃分后的業(yè)務(wù)邏輯流程直到業(yè)務(wù)結(jié)束頁面，最終通過一個場景或者多個場景覆蓋項目中包括的所有功能業(yè)務(wù)邏輯頁面，場景以一個腳本保存或多個腳本無影響。對于流程的前置條件重復(fù)可以錄制一遍，比如兩個業(yè)務(wù)場景都需要用戶登錄，那登錄操作的腳本只需要錄制一遍。手工測試方法針對手工測試覆蓋的兩種漏洞類型URLRedirect和Accesscontrol測試方法比較簡單，工具也只是用到瀏覽器及其插件。URL

Redirect漏洞的測試范圍是UC中設(shè)計的外部跳轉(zhuǎn)功能點，方法是如果跳轉(zhuǎn)目的URL為用戶輸入?yún)?shù)，只要通過瀏覽器插件將對應(yīng)參數(shù)改為非阿里巴巴的URL地址，然后發(fā)送請求后觀察跳轉(zhuǎn)頁面是否為非阿里巴巴網(wǎng)站，如果是則說明有URL跳轉(zhuǎn)的漏洞。Accesscontrol漏洞主要的測試方法是通過瀏覽器篡改HTTP請求的插件，獲得HTTP請求參數(shù)，并進(jìn)行非法參數(shù)替換并提交，查看服務(wù)端是否對權(quán)限進(jìn)行校驗?；蛘咧苯釉诘刂窓谄唇覷RL，測試服務(wù)端是否對訪問權(quán)限進(jìn)行校驗。安全測試手工測試用例規(guī)范見QC賬號：guest域：ALI_ICBU_TEST項目：英文站測試用例庫路徑：^Subject\_2011_測試用例體系\003_藏經(jīng)閣\03_安全類^列出了一些典型的安全測試手工測試用例，供參考。針對安全測試用例，在項目文件夾中增加”安全用例”文件夾。記錄安全漏洞的規(guī)范性Hatrix手工掃描--針對掃描出的安全漏洞進(jìn)行分析--將分析結(jié)果在QC上提交Bug，同時上傳相應(yīng)Hatrix工程于附件中。對大量的錄制進(jìn)行篩選，只提交由Bug的地方的工程。手工測試部分--對于安全漏洞在QC上提交Bug。BUG需進(jìn)行細(xì)分（必填）：缺陷類型--安全漏洞缺陷細(xì)分--CSRF/XSS/SQLInject/AccessControl/其它缺陷級別--high主要產(chǎn)出物1、《XXX項目/小需求代碼安全審核報告》——安全工程師2、《XXX項目/小需求安全測試工具輸出報告》——Hatrix自動導(dǎo)出3、《XXX項目/小需求安全測試傳遞清單》——QA記錄并備份說明：項目中安全測試質(zhì)量報告無需單獨發(fā)出，但在功能測試質(zhì)量報告中要說明安全測試的質(zhì)量情況。SVN地址：/repos/ali_QA/22_安全測試領(lǐng)域注意點說明自動化安全測試工具Hatirx存在部分場景無法適用的情況，比如：頁面中包含驗證碼（這種驗證碼包含顯示和隱藏兩種），由于工具無法獲取驗證碼所以會導(dǎo)致回放請求失敗。遇到類似情況，建議與開發(fā)協(xié)商繞過驗證碼校驗的方案，例：部署兩套環(huán)境，一套安全測試（修改代碼使服務(wù)端不驗證），一套功能測試。安全測試策略需要在測試計劃中明確定義，實施方法要明確說明并體現(xiàn)在測試分析中，如策略中需要手工測試，手工測試的用例編寫在QC平臺中，在測試計劃評審中review。是否進(jìn)行安全測試是在項目立項時由安全審核部門來確定，非項目經(jīng)理定義。如對項目中安全測試方法無法準(zhǔn)確把握，可以咨詢安全審核工程師（國際站接口人：姜禹）給出指導(dǎo)意見。由于fuzz原理，掃描過程中會提交大量數(shù)據(jù)。如果對臟數(shù)據(jù)比較敏感，請掃描后注意清理臟數(shù)據(jù)。推薦安全掃描報告的保存格式為RTF，以方便各執(zhí)行人閱讀。腳本錄制需注意的問題：按頁面或者功能錄制，不建議整個操作流程錄制一次，因為這樣可能有很多重復(fù)相同的http請求，保證相同的http請求只錄制一次。腳本錄制細(xì)節(jié)不關(guān)心提交表單的輸入?yún)?shù)組合（會被參數(shù)化），只關(guān)心提交表單這一操作。安全測試問題跟蹤流程，需注意：提出問題：將所發(fā)現(xiàn)的問題導(dǎo)出一份安全測試報告作為附件，并在QC里提安全bug給相應(yīng)開發(fā)工程師，保存錄制的腳本并以附件形式上傳于QC。修改問題確認(rèn)：開發(fā)工程師修改后把問題fixed掉，驗證前先和安全工程師確認(rèn)下修改點。問題驗證：再次用hatrix工具掃描錄制的腳本，驗證修改掉的問題，如果發(fā)現(xiàn)新問題或者已修改的問題沒修改好，可以reopen這個安全bug給相應(yīng)開發(fā)工程師。Web安全漏洞簡介及測試說明按照公司的實際應(yīng)用情況,我們目前主要面對的Web安全漏洞主要有以下五種:XSS,CSRF,SQLInjection,URLRedirect和AccessControl。XSS(CrossSiteScript)XSS(CrossSiteScript)，跨站腳本攻擊。它指的是\o"惡意攻擊"惡意攻擊者往Web頁面里插入惡意代碼，當(dāng)用戶\o"瀏覽"瀏覽該頁之時，嵌入其中Web里面的html代碼會被執(zhí)行，從而達(dá)到惡意用戶的特殊目的。比如惡意攻擊者將一段獲取Cookie的腳本持久化到頁面后，正常用戶訪問該頁面后其Cookie信息就會被攻擊者獲取。參見wiki：/wiki/Cross-site_scripting案例:下面是公司法務(wù)部投訴系統(tǒng)的截圖,圖中顯示的是一個登陸界面

圖示2-1登陸界面當(dāng)瀏覽器的url改為/legal/site/login/login.htm?site_type=%22%3E%3Cinput%20type=image%20src=x%20onerror=alert%28document.cookie%29%3E，瀏覽器顯示截圖如1-2，惡意用戶提交的js被成功執(zhí)行，所以說明系統(tǒng)的登錄功能中存在XSS漏洞。圖示2-2XSS漏洞主要采用Hatrix進(jìn)行測試，Hatrix會根據(jù)Http數(shù)據(jù)，構(gòu)建不同的測試用例進(jìn)行Fuzzer測試Fuzzer測試：Isasoftwaretestingtechniquethatprovidesinvalid,unexpected,orrandomdatatotheinputsofaprogram.Iftheprogramfails(forexample,bycrashingorfailingbuilt-incodeassertions),thedefectscanbenoted。Fuzzer測試：Isasoftwaretestingtechniquethatprovidesinvalid,unexpected,orrandomdatatotheinputsofaprogram.Iftheprogramfails(forexample,bycrashingorfailingbuilt-incodeassertions),thedefectscanbenoted。CSRF(Cross-siteRequestForgery)CSRF(Cross-siteRequestForgery)，跨站點請求偽造。通常指在某個惡意站點的頁面上，促使訪問者請求你的網(wǎng)站的某個URL（GET，POST提交方式均可），從而達(dá)到改變服務(wù)器端數(shù)據(jù)的目的。這一類攻擊依賴于你的網(wǎng)頁中的表單，脆弱的表單很容易受到攻擊。比如A站點有一刪除功能URL為：/deleteB站點一頁面中有這樣一段代碼：<imgsrc=”/delete”/>這樣用戶瀏覽B站點的該頁面時，隨即也觸發(fā)了A站點的刪除功能。參見wiki：/wiki/CSRF案例:下圖是阿里巴巴國際站登錄后top截圖,可以看到用戶intldev已經(jīng)登錄這時用戶訪問csrfsignout.html頁面，注意這并不是原來alibaba域名下的，而是本地的一個頁面：然后再刷新頁面，截圖如下：這時用戶intdev已經(jīng)不處于登錄狀態(tài)，但是這個期間并沒有做退出操作，原因就在于csrfsignout.html的這張圖片，代碼是：<imgsrc="/user/sign/sign_out.htm"onerror="this.src='/images/eng/style/logo/logo_alibaba.gif';"/>圖片做了退出的請求，因此用戶就不知情的做了一個合法操作，這就是個簡單CSRF攻擊。CSRF的檢測比較簡單，主要還是通過Hatirx工具進(jìn)行掃描測試，只要在form中檢測是否存在_csrf_token_即可。但是CSRF漏洞之間的威脅程度是不同的，CSRF漏洞的嚴(yán)重程度是和form本身的作用有關(guān)的，對于一些敏感數(shù)據(jù)的操作，比如用戶信息的CRUD是一定需要加入_csrf_token_TToken：用來防止CSRF漏洞和重復(fù)提交的認(rèn)證碼，服務(wù)端發(fā)送的http中包括一個hidden屬性的認(rèn)證碼，客戶端提交請求時會將該認(rèn)證碼一并提交，服務(wù)端接收后與發(fā)送的碼進(jìn)行比對，如果一致認(rèn)為合法，如果不一致有可能該提交已過期或者非法，如果已接收過認(rèn)為是重復(fù)提交。SQLInjectionSQLInjection就是向服務(wù)器端提交事先準(zhǔn)備好的數(shù)據(jù)，拼湊出攻擊者想要的SQL語句，以改變數(shù)據(jù)庫操作執(zhí)行計劃。比如有一sql語句是select*fromUSERwhereUSER.id=idandUSER.read=’true’,而id的數(shù)據(jù)來自于用戶的請求：/get?id=1這樣用戶只要用提交/get?id=1or1=1即可直接忽略sql中其他條件判斷了。參見wiki/wiki/Sql_injection現(xiàn)有的防SQLInjection開發(fā)方案都是基IBatis的，所以在基于IBatis開發(fā)的應(yīng)用中出現(xiàn)SQLInjection的可能性比較小。但是Hatrix的SQLInjection檢測是基于返回信息中的數(shù)據(jù)庫信息，對于進(jìn)行錯誤處理的程序是很難進(jìn)行檢測的，比如自動跳轉(zhuǎn)到404頁面。所以如果測試工程遇到非IBatis開發(fā)的項目，可能需要手動構(gòu)建SQLInjection的測試用例，這些用例可以參考hatrix中模版HHatrix模版:參考4.6節(jié)。URLRedirectURL跳轉(zhuǎn)的應(yīng)用很廣，在這里我們只局限于可以修改URL地址的跳轉(zhuǎn)，比如正確登錄后的跳轉(zhuǎn)到之前頁。這個之前頁的URL地址就是可以修改的，是不確定的。URLRedirect的主要威脅在于釣魚網(wǎng)站，惡意用戶可以利用URLRedirect將有惡意跳轉(zhuǎn)的URL轉(zhuǎn)發(fā)給其他用戶，而此URL同時能順利逃過域名檢測，比如/?Done=/如果URLRedirect檢測不嚴(yán)格，登錄之后即跳轉(zhuǎn)到案例：下圖瀏覽器地址顯示的是一個淘寶的合法url地址，由于該應(yīng)用對url過濾不嚴(yán)格，接受了參數(shù)url=2/RmfishServlet/urldirect,并以該url做了一次跳轉(zhuǎn)，于是用戶在訪問taobao頁面時，實質(zhì)是請求了一個第三方網(wǎng)頁，可想這個危險有多大！URL跳轉(zhuǎn)本身是屬于業(yè)務(wù)邏輯跳轉(zhuǎn)的一種實現(xiàn)，所以工具檢測成本比較高，同時應(yīng)用中URLRedirect數(shù)量比較小，在需求文檔中應(yīng)該有描述，所以URLRedirect漏洞需要測試進(jìn)行手動檢測，主要的檢測方法是采用手工的方式將目的URL地址替換成非阿里巴巴域名的URL地址，檢測是否會跳轉(zhuǎn)到非阿里巴巴的網(wǎng)站。AccessControl這里的訪問控制主要是一些越權(quán)操作漏洞。AccessControl主要包括了水平權(quán)限和垂直權(quán)限兩種，水平權(quán)限是指能訪問其他用戶受保護(hù)的內(nèi)容，從權(quán)限關(guān)系的角度來看，這種情況突破了權(quán)限的水平約束。垂直權(quán)限問題就是訪問需要更高授權(quán)的資源，比如未登錄用戶能夠訪問需要登錄的資源，普通用戶訪問須管理員權(quán)限的資源等，從權(quán)限關(guān)系的角度看，這種情況是突破了權(quán)限的垂直約束，獲取到了更高權(quán)限。案例:下圖是國際站MyalibabaContacts模塊下的ManageContacts,其中有個一個查詢聯(lián)系人的功能，url為/mcadmin/contact/contactDetailInfo.htm?cid=XXX，XXX為一個聯(lián)系人的ID，如下圖所示，這個頁面沒有問題，因為ID為63488082聯(lián)系人就是屬于當(dāng)前用戶的聯(lián)系人，但是問題在于當(dāng)惡意用戶修改了cid后就能任意獲取到其他聯(lián)系人的信息，即使該聯(lián)系人并不是該用戶的聯(lián)系人，如圖所示，ID為63422XXX的用戶信息被獲取了，但是他并不是當(dāng)前用戶的聯(lián)系人。這就是一個AccessControl漏洞。應(yīng)用中的越權(quán)操作的檢測需要對應(yīng)用的業(yè)務(wù)邏輯和數(shù)據(jù)扭轉(zhuǎn)有很清晰的了解，所有現(xiàn)階段框架上和工具上沒有合適的解決方案，此類漏洞只能依賴于手工測試。而手工測試的方法主要有兩種：1）用戶對私有資源的訪問或是操作，比如訪問用戶的信息，如聯(lián)系人信息，這就是訪問屬于用戶的私有信息；還比如修改用戶信息和刪除郵件，用戶能修改和刪除一定只能是歸屬于用戶的資源。類似的例子有很多，它們的共同點就是，這些操作基本都依賴于一個ID，也就是操作資源的標(biāo)示符。所以測試的時候就需要把這個標(biāo)示符替換掉，換成其他不屬于用戶操作范圍資源的標(biāo)示符，并通過操作結(jié)果來判斷程序是否存在AccessControl的漏洞問題。2）不同用戶身份之間的越權(quán)。比如未登錄用戶向服務(wù)器請求一個登錄用戶的才能訪問的url，如果未登錄用戶同樣能訪問，那說明存在AccessControl漏洞。同樣一個普通用戶訪問一個只有管理員權(quán)限的資源，也需要做越權(quán)檢測。這類漏洞需要測試人員在不同身份賬號，或是不同權(quán)限授權(quán)下對更高授權(quán)的資源進(jìn)行請求測試，以此來發(fā)現(xiàn)是否存在AccessControl漏洞。上傳下載文件安全威脅：Fileupload，任意文件上傳威脅。Web應(yīng)用程序在處理用戶上傳的文件時，沒有判斷文件的擴展名是否在允許的范圍內(nèi)，就把文件保存在服務(wù)器上，導(dǎo)致惡意用戶可以上傳任意文件，甚至上傳腳本木馬到web服務(wù)器上，直接控制web服務(wù)器。防御方案 每個上傳需求點都要明確允許上傳的文件類型，程序?qū)崿F(xiàn)時要在服務(wù)器端對文件進(jìn)行類型檢測。同時上傳的文件要保存至沒具有代碼執(zhí)行能力的專門存儲服務(wù)器上，不能保存在Web應(yīng)用目錄下。對于上傳的圖片類型的文件，必須要進(jìn)行圖片格式化，即將圖片讀入再重新生成一張新的圖片。2.7Flash安全為了提高阿里巴巴信息系統(tǒng)的安全性，規(guī)范集團(tuán)內(nèi)部FLASH的開發(fā)及部署規(guī)范，特制定本配置規(guī)范。1.服務(wù)端Crossdomain.xml訪問策略文件的安全需求安全關(guān)注點：不當(dāng)?shù)腸rossdomain.xml配置解決方案：如果沒有flash應(yīng)用，禁止配置crossdomain.xml策略文件，如果有，需要定允許的跨域請求的域，詳細(xì)請參考參考安全中心的flash安全部署與開發(fā)規(guī)范2.用戶上傳flash功能的安全需求安全關(guān)注點：利用flash進(jìn)行跨站或者csrf攻擊解決方案：用戶上傳的flash文件上傳到單獨域名下，詳細(xì)請參考參考安全中心的flash安全開發(fā)與部署規(guī)范3.項目中的flash是否有與瀏覽器交互的需求安全關(guān)注點：我們自己開發(fā)的flash文件也可能存在漏洞解決方案：如果沒有特殊需求需要設(shè)置allowscriptaccess屬性為never，詳細(xì)請參考參考安全中心的flash安全部署與開發(fā)規(guī)范4.項目中的flash是否有與遠(yuǎn)程通信的需求安全關(guān)注點：客戶端直接提交數(shù)據(jù)與flash文件通訊解決方案：如果沒有特殊需求需要設(shè)置allowNetworking為none，詳細(xì)請參考參考安全中心的flash安全部署與開發(fā)規(guī)范從Web安全測試的角度可以把以上五種安全漏洞類型分成兩類：代碼執(zhí)行漏洞，功能邏輯漏洞。代碼執(zhí)行漏洞是因為輸入中有非法操作，而且這些操作通過某些方式在某處以某些權(quán)限被執(zhí)行。其中XSS，CSRF，SQLInjection都屬于代碼執(zhí)行漏洞，這種漏洞自身和攻擊方法都具有很強的可識別性，因為其威脅主要來自于程序直接使用了用戶提交的數(shù)據(jù)，所以對用戶的輸入進(jìn)行處理就能很好應(yīng)對此類漏洞。所以對于這三類漏洞，在框架、工具以及開發(fā)規(guī)范上都是比較容易解決的。功能邏輯漏洞分兩類，一種是在應(yīng)用設(shè)計階段錯誤的邏輯設(shè)計導(dǎo)致的，另一種就是代碼中忽略或是錯誤的描述了應(yīng)用邏輯。所以功能邏輯漏洞并不一定是代碼本身的缺陷，可能依托代碼執(zhí)行的應(yīng)用邏輯出錯。AccessControl漏洞就是屬于這類，URLRedirect、Flash安全、上傳下載文件也可以理解為此類漏洞。自動化工具Hatirx介紹自動化工具Hatirx安全自動化測試工具主要采用，集團(tuán)安全部門開發(fā)的Hatrix，工具的下載頁面是：/twiki/bin/view/Security/SecurityProject/Hatrix_Web_Vulnerability_Scanner工具使用的視頻教程地址是：/twiki/pub/Security/SecurityProject/Hatrix_Web_Vulnerability_Scanner/hatrix_demo.rarHatirx工具使用安全測試過程中工具h(yuǎn)atirx的操作流程：打開準(zhǔn)備進(jìn)行安全測試的頁面。打開hatirx安全測試工具。點擊DeepScan按鈕，準(zhǔn)備開始掃描，該選項為默認(rèn)選項。點擊按鈕，使hatirx處于錄制http交互的狀態(tài)。按照預(yù)想測試的流程Hatirx工具支持多頁面連續(xù)錄制，只要頁面沒有驗證碼等防重復(fù)提交校驗值。Hatirx工具支持多頁面連續(xù)錄制，只要頁面沒有驗證碼等防重復(fù)提交校驗值。點擊按鈕，結(jié)束錄制。在下拉框中選擇，該選項也是默認(rèn)選項。點擊按鈕，進(jìn)行預(yù)掃描。預(yù)掃描是什么概念？為了提高工具的掃描速度，工具根據(jù)內(nèi)部規(guī)則（對每個http請求參數(shù)只進(jìn)行一次隨機數(shù)替換，如果頁面返回值中不包括該隨機數(shù)，即認(rèn)為不會有漏洞，在正式掃面中不會對該參數(shù)掃描，也就是說預(yù)掃描并不是用來檢測漏洞的而是檢測請求的參數(shù)是否對應(yīng)返回。例如，一個頁面的http請求有10個參數(shù)，那么會每次使用一個隨機數(shù)替換一個請求參數(shù)，整個預(yù)掃滿過程也就是回放10次表單提交，用來檢測這10個參數(shù)有哪些是沒有返回值，哪些是有返回值。如果沒有預(yù)掃滿過，針對該頁面的正式掃描還是這10個參數(shù)，每次執(zhí)行每個參數(shù)替換漏洞庫中的一條特征碼，如果漏洞庫中定義50條特征碼，那么一共會回放10×50＝500次表單提交。如果經(jīng)過預(yù)掃描，認(rèn)為有7個參數(shù)沒有返回值則不會產(chǎn)生漏洞，那么只需要3×50＝150次表單提交，這樣會大大減少回放次數(shù)，也就減少了運行時間。）自動識別哪些參數(shù)需要掃描哪些參數(shù)不需要掃描，這樣既保證了掃描的有效性同時又提高了效率。預(yù)掃描和預(yù)掃描全部的區(qū)別？預(yù)掃描會掃描當(dāng)前鼠標(biāo)選中的url地址，而預(yù)掃描全部會掃描當(dāng)前選中的url地址及列表位該選中項以下的全部地址。掃描和掃描全部的概念類似。點擊按鈕，進(jìn)行全面掃描。當(dāng)掃描的url前顯示綠色對號時，代表該地址掃描結(jié)束，并且沒有發(fā)現(xiàn)安全漏洞。當(dāng)掃描的URL前顯示紅色感嘆號時，代表該地址掃描結(jié)束，同時發(fā)現(xiàn)有安全漏洞。掃描完全結(jié)束后會自動提示掃描結(jié)束。如果掃描結(jié)果發(fā)現(xiàn)漏洞，點擊按鈕的加號，顯示所有掃描出的漏洞，如果查看漏洞詳細(xì)信息，選中具體發(fā)現(xiàn)的漏洞。漏洞的詳細(xì)信息在頁面右側(cè)顯示（注意：此時一定要選中漏洞才會顯示4個tab頁，否則只顯示2個tab頁）。。Infor：本次掃描的整體結(jié)果簡介。ViewSource：查看掃描url的html源碼，漏洞位置及腳本會高亮顯示。Browser：通過內(nèi)嵌瀏覽器渲染該url地址的頁面。Description：該漏洞的詳細(xì)描述。點擊按鈕，導(dǎo)出本次安全掃描結(jié)果。點擊按鈕，進(jìn)行場景和結(jié)果保存，在1.24版中，保存功能增加了掃描結(jié)果的保存，不僅僅是保存了錄制的URL還有這些URL掃描后的結(jié)果，該結(jié)果比報表中描述的內(nèi)容更加全面，所以建議掃描后一定要保存。報表中信息表單中提交的數(shù)據(jù)腳本錄制時訪問的url表單中提交的數(shù)據(jù)腳本錄制時訪問的urlhttp的提交表單名稱服務(wù)端響應(yīng)的關(guān)鍵字上下文漏洞類型，主要有：XSS、csrf、SQLinjection、DataInvalid 返回值中包含特征值手動測試工具當(dāng)漏洞類型或場景不適用自動化工具時，需要手動測試，手動測試根據(jù)每個人的習(xí)慣不同而方法工具不同，不過我們推薦的組合有Firefox+Firebug+TemperData以上工具，只需要在google搜索關(guān)鍵字就能夠很容易下載安裝。以上工具，只需要在google搜索關(guān)鍵字就能夠很容易下載安裝。安全工具的原理實際上安全工具只是通過錄制和回放，將安全部門整理的漏洞特征代碼進(jìn)行提交和驗證。其原理和目前網(wǎng)站自動化原理基本類似，都是包括輸入項、實際結(jié)果和預(yù)期結(jié)果并進(jìn)行比較。如果實際結(jié)果中有預(yù)期的特征代碼一致即認(rèn)為有漏洞。其實手工完全可以自己輸入漏洞特征代碼并比較預(yù)期結(jié)果以達(dá)到和自動化工具一樣的效果。漏洞特征代碼庫在哪里？在1.24版本中，所有的漏洞特征碼已存放在服務(wù)器端，由程序運行時從服務(wù)端取，本地客戶端無法配置。Hatrix工具注意事項禁止使用Hatirx工具掃描阿里巴巴線上應(yīng)用以及其他網(wǎng)站的生產(chǎn)線上環(huán)境。因為本工具會產(chǎn)生大量http請求，服務(wù)器處理這些請求會占用大量資源，所以禁止掃描任何線上網(wǎng)站，Hatrix工具只適用于測試環(huán)境。安全測試分析舉例這里用Myalibaba普通會員的Contacts功能作為例子，給大家演示一下安全工程師是如何分析安全問題的簡要過程：如圖5-1所示，Contacts主要包括了AddNewContact;MyContacts;ManageContacts;Settings;EmailAlert;BlockList;MatchingSellers幾個子功能，其中MyContacts的部分功能屬于AccountSettings，MatchingSellers屬于SellingTools。這里對這部分不做討論，只分析屬于Contacts的功能。通過分析可以得出這幾個功能的特點:圖示4-1Myalibaba的Contacts功能AddNewContact是一個表單提交,里面涉及了部分?jǐn)?shù)據(jù)驗證。圖示4-1Myalibaba的Contacts功能MyContacts是一個人相關(guān)信息的查詢，是基本的Get請求，不涉及數(shù)據(jù)提交。ManageContacts中包括了Contacts的刪除、修改，發(fā)送消息的功能。都是采用表單實現(xiàn)功能的。Settings中包括了Folders,ContactGroup,Templates,BlockList,ContactSettings的子功能，其中前4個子功能類似，都包括了新建、編輯和刪除功能，也都是采用表單實現(xiàn)的。EmailAlert和BlockList都是一個表單提交。通過上面的簡單分析，能明白Contacts的功能點和基本技術(shù)實現(xiàn)。然后綜合考慮Contacts涉及的有表單提交，Get請求，數(shù)據(jù)驗證，權(quán)限控制這些操作。這里可以用Hatrix自動化工具掃描的也比較清楚了，上面提到所有涉及request的地方，包括Post表單和Get請求，經(jīng)過Hatrix掃描后能掃出這些地方是否存在XSS，CSRF和SQLInjection漏洞。但是這還是不夠，因為Hatrix提交的數(shù)據(jù)只是一些具有攻擊特征的代碼，不能發(fā)現(xiàn)程序邏輯上的問題。在Contacts中有業(yè)務(wù)邏輯的包括了數(shù)據(jù)驗證和權(quán)限控制，數(shù)據(jù)驗證包括了表單中一些限制，比如AddNewContact中名字只能采用英文，Products/Services有字?jǐn)?shù)限制，郵箱格式限制等。這部分是需要測試手工測試的。權(quán)限控制我們單獨討論，程序權(quán)