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

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

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

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

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

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

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