畢業(yè)論文-Web應(yīng)用程序安全漏洞知識庫初探

鹽城師范學(xué)院畢業(yè)設(shè)計(jì)畢業(yè)設(shè)計(jì)Web應(yīng)用程序安全漏洞知識庫初探學(xué)生姓名學(xué)院專業(yè)計(jì)算機(jī)科學(xué)與技術(shù)班級學(xué)號指導(dǎo)教師2016年5月16日Web應(yīng)用程序安全漏洞知識庫初探摘要隨著互聯(lián)網(wǎng)的迅速發(fā)展，目前很多業(yè)務(wù)都依賴于互聯(lián)網(wǎng)，比如網(wǎng)上銀行業(yè)務(wù)、旅游在線購票業(yè)務(wù)、網(wǎng)上購物業(yè)務(wù)等，Web應(yīng)用程序和人們的日常生活息息相關(guān)。很多惡意攻擊者會想法設(shè)法對Web服務(wù)器進(jìn)行攻擊，從中盜取他人的個(gè)人賬戶信息來換取他們的利益。為了防止惡意攻擊者的攻擊，除了對Web服務(wù)器做相應(yīng)的安全配置外，Web應(yīng)用程序的設(shè)計(jì)和實(shí)現(xiàn)過程中也需要排除惡意攻擊者攻擊的隱患。但是在互聯(lián)網(wǎng)上還無法找到對于Web應(yīng)用程序安全漏洞的系統(tǒng)性介紹工具或文章，這對程序開發(fā)人員對于漏洞機(jī)理的理解也造成了困擾。本文主要對OWASPTOP102013的十大安全漏洞進(jìn)行分析和整理研究。文中介紹了OWASPTOP10的相關(guān)漏洞的機(jī)理研究以及預(yù)防措施。針對所整理的內(nèi)容制作Web應(yīng)用程序安全安全漏洞展示系統(tǒng)，系統(tǒng)包括用戶注冊以及登錄界面，調(diào)研內(nèi)容展示模塊。系統(tǒng)運(yùn)用軟件開發(fā)流程的方法進(jìn)行相應(yīng)的需求分析，然后基于C#語言進(jìn)行系統(tǒng)編碼，設(shè)計(jì)并且實(shí)現(xiàn)了Web應(yīng)用程序安全漏洞展示系統(tǒng)。分析這些經(jīng)典的漏洞，旨在幫助程序開發(fā)員提升他們的編碼安全意識，加強(qiáng)Web應(yīng)用程序的安全性?！娟P(guān)鍵詞】Web；應(yīng)用程序；漏洞展示；OWASPTOP102013TheDesignandImplementationofWebApplicationSecurityVulnerabilitiesKnowledgeBaseABSTRACTWiththerapiddevelopmentoftheInternet,manybusinessesrelyontheInternet,suchasonlinebanking,onlinetravelbookingservices,onlineshoppingservices,etc.TheWebapplicationprogramiscloselylinkedwithpeople'slife.ManymaliciousattackersfindwaystoattacktheWebserverfortheirbenefitsbystealingpeople'spersonalaccountinformation.Therefore,Webservicesplatformisoftenunderattack.InadditiontotheWebservertodothecorrespondingconfiguration,Webapplicationdesignanddevelopmentprocessalsoneedtoexcludetheriskofmaliciousattacks.Howeverweyetcouldn'tfindthesystematicintroductiontooloressayforWebapplicationprogramsecurityvulnerabilities,Whichperplexestheunderstandingofvulnerabilitymechanismfortheapplicationdeveloper.ThisthesisfocusesonOWASPTOP102013Ten-securityvulnerabilityanalysisandorganizesresearch.ThispaperdescribesthemechanismanalysisandpreventivemeasuresofOWASPTOP10thatrelatedvulnerabilities.TheproductionofWebapplicationprogramsecurityvulnerabilitiespresentationsystemisbasedoncollativecontents,whichincludinguserregistrationandloginscreen,theresearchcontentdisplaymodule.SystemdoestherelevantdemandanalysisbyusingthemethodofsoftwaredevelopmentprocessandbasingonC#languagetosystemscode,designandrealizeaWebapplicationprogramsecurityvulnerabilitiesdisplaysystem.AnalysesoftheseclassicloopholesaimtohelpprogrammerstoenhancetheircodingsecurityawarenessandstrengthenthesecurityofWebapplications.[Keywords]Web,Applicationprogram,Displaysystem,OWASPTOP10201323

目錄259991引言 頁，共48頁1引言1.1研究背景與應(yīng)用前景伴隨著科技的快速發(fā)展，互聯(lián)網(wǎng)行業(yè)成為了當(dāng)今最熱門、發(fā)展前景最好的行業(yè)。Internet已經(jīng)成為世界上一個(gè)非常重要的基礎(chǔ)平臺，很多企業(yè)都將應(yīng)用架設(shè)在該平臺上，為了給客戶提供更加方便和快捷的服務(wù)支持。這些Web應(yīng)用在功能和性能上都在不斷的完善和提高，但是在最重要的安全性上，卻常常遭受到忽略。因?yàn)楝F(xiàn)在的網(wǎng)絡(luò)技術(shù)慢慢變得成熟，黑客們也把對網(wǎng)絡(luò)服務(wù)器的攻擊的注意力都漸漸轉(zhuǎn)移到了對Web應(yīng)用程序的攻擊上面。根據(jù)Gartner的最新調(diào)查，信息安全攻擊有75%都是發(fā)生在Web應(yīng)用而不是網(wǎng)絡(luò)層面上。與此同時(shí)，數(shù)據(jù)也顯示出將近三分之二的Web站點(diǎn)都相當(dāng)容易遭受攻擊[1]。目前的形式是，大部分的企業(yè)都在網(wǎng)絡(luò)和服務(wù)器的安全上花費(fèi)了大量的資金，卻沒有實(shí)質(zhì)地保證Web應(yīng)用本身的安全，給惡意攻擊者提供了攻擊的機(jī)會。Web攻擊是當(dāng)前數(shù)據(jù)竊取的主要途徑。相關(guān)數(shù)據(jù)顯示當(dāng)前57%的數(shù)據(jù)竊取攻擊都是經(jīng)由對Web的攻擊來實(shí)現(xiàn)。Web的攻擊威脅是偷偷進(jìn)入企業(yè)網(wǎng)絡(luò)在用戶完全沒有察覺的情況下，從而對公司的業(yè)務(wù)造成極大威脅，其中這些威脅包含對數(shù)據(jù)資產(chǎn)的盜取、行業(yè)信譽(yù)的破壞以及關(guān)鍵業(yè)務(wù)的竊取。即使一些看起來不重要的信息，經(jīng)過盜取者的匯集和歸納，后果也可能導(dǎo)致公司內(nèi)部設(shè)置、核心客戶等重要信息泄露。根據(jù)C#的軟件開發(fā)與設(shè)計(jì)規(guī)范，本文基于該平臺上設(shè)計(jì)并實(shí)現(xiàn)了這個(gè)Web應(yīng)用程序安全漏洞展示系統(tǒng)軟件。它里面的內(nèi)容著重詳述了當(dāng)前熱門的OWASPTOP10漏洞的成因、歷史事件、和漏洞防范等。為程序開發(fā)者提供方便快捷地查詢以及提升防范意識。1.2本文的論文工作介紹研究工作：近幾年來，由于互聯(lián)網(wǎng)的飛速發(fā)展，人們的生活已經(jīng)離不開互聯(lián)網(wǎng)。本人根據(jù)Web許多安全方面頻頻遭受攻擊，對OWASPTOP102013的十大漏洞進(jìn)行分析和調(diào)研。將漏洞的機(jī)理、修復(fù)方法、檢測方法以及預(yù)防方法進(jìn)行整合。實(shí)現(xiàn)工作：本人通過學(xué)習(xí)查閱C#開發(fā)資料設(shè)計(jì)并實(shí)現(xiàn)了本W(wǎng)eb代碼安全漏洞展示系統(tǒng)。實(shí)現(xiàn)了系統(tǒng)的前端用戶注冊登錄界面，以及漏洞各方面的詳述。通過查閱網(wǎng)站上的博客以及書籍，將OWASPTOP102013的漏洞進(jìn)行了詳細(xì)地整理。（1）構(gòu)造程序漏洞及其機(jī)理分析框架：定義－威脅－成因－檢測方法－修復(fù)建議－預(yù)防辦法。（2）基于漏洞分析框架，針對2013年OWASPTOP10漏洞進(jìn)行分析：1）注入式漏洞2）跨站腳本攻擊3）不正確的直接對象引用漏洞4）偽造跨站請求漏洞5）未驗(yàn)證的重定向和轉(zhuǎn)發(fā)漏洞6）安全配置錯(cuò)誤漏洞7）敏感數(shù)據(jù)暴露漏洞8）使用已知易受攻擊的組件漏洞9）缺少功能層面的訪問控制漏洞10）錯(cuò)誤的會話認(rèn)證和會話管理漏洞（3）基于漏洞分析，構(gòu)造漏洞知識庫系統(tǒng)：1）注冊子系統(tǒng)2）登錄子系統(tǒng)3）漏洞知識展示子系統(tǒng)1.3論文組織結(jié)構(gòu)第一部分引言部分。介紹了項(xiàng)目的研究背景以及應(yīng)用前景，和對于論文工作的一個(gè)簡要綜述。第二部分Web應(yīng)用程序漏洞分析框架部分。將項(xiàng)目所設(shè)計(jì)到的經(jīng)典漏洞依次進(jìn)行詳細(xì)的介紹。主要是對漏洞的定義、威脅、成因、檢測方法、修復(fù)方法和預(yù)防方法進(jìn)行解釋說明。第三部分系統(tǒng)分析與設(shè)計(jì)部分。提出項(xiàng)目需求，根據(jù)需求對項(xiàng)目包含的主要業(yè)務(wù)進(jìn)行介紹，對項(xiàng)目的主要模塊進(jìn)行劃分和介紹。對于核心業(yè)務(wù)模塊的實(shí)現(xiàn)方法重點(diǎn)詳述，其中包括登陸模塊、注冊模塊和漏洞知識展示模塊。2Web應(yīng)用程序漏洞分析框架根據(jù)對系統(tǒng)的需求分析，創(chuàng)建一個(gè)帶有登錄和注冊功能的漏洞知識庫，主要包含登錄和注冊界面和對漏洞詳細(xì)介紹的界面，漏洞知識庫中著重講解了OWASP（TheOpenWebApplicationSecurityProject，開放式Web應(yīng)用程序安全項(xiàng)目）2013TOP10漏洞，經(jīng)過調(diào)研和整理完成漏洞知識庫的初探，典型漏洞有注入式漏洞、跨站腳本攻擊漏洞、不正確的直接對象引用漏洞、偽造跨站請求漏洞、未驗(yàn)證的重定向和轉(zhuǎn)發(fā)漏洞、安全配置錯(cuò)誤漏洞、敏感數(shù)據(jù)暴露漏洞、使用已知易受攻擊組件漏洞、缺少功能層面訪問控制漏洞、錯(cuò)誤的會話認(rèn)證和會話管理這十大漏洞，下面對于各個(gè)漏洞的定義、成因、經(jīng)典案例、檢測方法和防范方法進(jìn)行依次介紹。2.1注入式漏洞簡介2.1.1注入式漏洞定義注入式攻擊主要是利用系統(tǒng)中某一模塊或組建的設(shè)計(jì)約定、語法約定等特點(diǎn)，采用組成新的合法設(shè)計(jì)、合法語法的方式來獲得新的解釋進(jìn)行攻擊。在這個(gè)解釋中，有一部分內(nèi)容根本不是程序設(shè)計(jì)者的愿意，這部分是被攻擊者在原意的基礎(chǔ)上新注入的，因此被稱為注入式攻擊。根據(jù)注入問題產(chǎn)生的原因和背景，注入可以分為很多種類型：OS命令注入、XPath注入、SSI注入、SQL注入、LDAP注入、XML注入以及XQuery注入等。2.1.2SQL注入產(chǎn)生的原因及過程根據(jù)不同的數(shù)據(jù)支持的SQL語法不同，SQL注入產(chǎn)生的原因也有可能不同，但是其根本原因是相似的，原因主要有以下幾種：（1）組合SQL命令中，可以注入注釋，比如，兩個(gè)連續(xù)的減號字符“--”后的文字為注解，或者由“/*”與“*/”包圍起來的文字為注釋。（2）在組合SQL的命令字符串時(shí)，如果沒有針對“’”這個(gè)特殊字符進(jìn)行取代處理，將會導(dǎo)致該字符串在填入命令字符串時(shí)，惡意篡改原來的SQL語句結(jié)構(gòu)的作用。（3）SQL命令可以進(jìn)行插入、查詢、刪除、更新等操作，也可以將這些命令傳戒起來，采用分號字符區(qū)分不同命令。（4）SQL命令對于傳入的字符串參數(shù)使用單引號字符包圍起來的，同時(shí)SQL也規(guī)定了連續(xù)兩個(gè)單引號字符在SQL數(shù)據(jù)庫中被視為字符串中的一個(gè)單引號字符，那么在這種情況下，單引號就被轉(zhuǎn)義了[6]。具體注入過程如圖2-1所示：圖2-1SQL注入過程圖2-2SQL注入界面1）惡意攻擊者首先對登錄界面進(jìn)行訪問，界面如圖2-2所示。2）惡意攻擊者填寫用戶名和密碼，點(diǎn)擊提交按鈕，應(yīng)用程序Web服務(wù)器接受到惡意攻擊者提交的內(nèi)容。3）這些含有攻擊的字符串在應(yīng)用程序Web服務(wù)器被組成的SQL語句，同時(shí)轉(zhuǎn)發(fā)給數(shù)據(jù)庫服務(wù)器執(zhí)行。4）應(yīng)用程序服務(wù)器接收來自于數(shù)據(jù)庫的執(zhí)行結(jié)果。5）瀏覽器接收來自應(yīng)用程序發(fā)送的內(nèi)容，這時(shí)惡意攻擊者可以在瀏覽器上看到注入的數(shù)據(jù)執(zhí)行結(jié)果，然后登錄進(jìn)去，完成此次攻擊。2.1.3SQL注入漏洞經(jīng)典案例及修改方法經(jīng)典案例：登錄網(wǎng)站的SQL代碼可能為：Stringusername=request.getParameter(“username”);Stringpassword=request.getParameter(“password”);Stringquery=”SELECTidFROMusersWHEREusername=”+username+”ANDpassword=”+password;Statementstmt=con.executeStatement(query);ResultSetrs=con.executeQuery(query);If(rs.next()){//登錄成功…}else{//登錄失敗…}假設(shè)有一個(gè)名叫John的用戶密碼為abcd，那么登錄時(shí)，形成的SQL語句如下：SELECTidFROMusersWHEREusername=’John’ANDpassword=’abcd’如果惡意輸入用戶名：uername=“’OR’1’=’1”;或者輸入密碼為：Password=“’OR’1’=’1”;將會導(dǎo)致原來的SQL語句篡改為：StrSQL=”SELECTidFROMusersWHEREusername=’’OR’1’=’1ANDpassword=’’OR’1’=’1’”;對于SQL解析器來說，這是一個(gè)可以正確解析并且可以被執(zhí)行的SQL語句，事實(shí)上它確實(shí)被執(zhí)行了，執(zhí)行的結(jié)果實(shí)際上等效于：SELECTidFROMusers;只要數(shù)據(jù)庫有數(shù)據(jù)，那么這條語句就可以獲取users表中每一條記錄，有的Web應(yīng)用程序會選擇返回的第一條記錄作為登錄的用戶，而很多系統(tǒng)可能第一個(gè)用戶是管理員，那么情況就會更糟。通過這種方式，可以實(shí)現(xiàn)即使沒有賬號，也可以登錄。另外，如果惡意輸入用戶名：Username=”’OR’1’=’1”;droptableusers;--結(jié)果SQL仍然可以正確解析，并且被執(zhí)行，這樣會導(dǎo)致users表被刪除，所有用戶將不能再登錄。解決方法：可以把用戶登錄的代碼改為：Stringusername=request.getParameter(“username”);Stringpassword=request.getParameter(“password”);Stringquery=”SELECTidFROMusersWHEREusername=：nmANDpassword=：pw”;Queryquery=session.createQuery(query)Query.setString(“nm”,user)Query.setString(“pw”,pass)2.1.4SQL注入的檢測方法以及檢測工具對于利用Web進(jìn)行的攻擊，變化比較多樣，隱蔽性也非常強(qiáng)，不易被發(fā)覺，因?yàn)槠胀ǚ阑饓TTP/HTTPS是完全開放的，傳統(tǒng)的IDS（IntrusionDetectionSystems，入侵檢測系統(tǒng)）對其也不起什么作用。對于SQL注入的檢測，目前主要通過以下兩種途徑進(jìn)行。第一種途徑就是通過Get方法發(fā)送的請求的參數(shù)的后面添加單引號（’）看看是否有報(bào)錯(cuò)。如果是SQL執(zhí)行有錯(cuò)，可能就存在SQL注入的風(fēng)險(xiǎn)。例如，SQLServer報(bào)錯(cuò)如下：MicrosoftJETDatabaseEngine錯(cuò)誤‘80040e14’字符串的語法錯(cuò)誤在查詢表達(dá)式‘id=16’中。/login.asp，行23如果使用的是IE瀏覽器，可能看到的是顯示500的錯(cuò)誤，而不是這些具體的信息，可以修改瀏覽器設(shè)置，具體方法是選擇“工具->Internet選項(xiàng)->高級”，取消“顯示友好HTTP錯(cuò)誤信息”的勾選即可。對于不同的參數(shù)，判斷方法也不稍有不同。（1）整形參數(shù)當(dāng)輸入的參數(shù)是整形時(shí)，如ID、年齡、個(gè)數(shù)等，若是查詢操作，可以猜測SQL語句大致如下：select*fromtablewhere字段名=輸入的值測試步驟如下。1）：HTTP:///test.asp?id=1’，如果SQL查詢語句變成select*fromtablewhereid=1’，那么test.asp會出現(xiàn)運(yùn)行異常。2）：HTTP:///test.asp?id=1and1=1，頁面運(yùn)行正常，且結(jié)果與HTTP:///test.asp?id=1運(yùn)行結(jié)果相同。3）：HTTP:///test.asp?id=1and1=2，運(yùn)行出現(xiàn)異常或者和HTTP:///test.asp?id=1運(yùn)行結(jié)果不同。如果以上三步全部滿足，則一定存在SQL注入漏洞。（2）字符串參數(shù)當(dāng)輸入的字符串是字符串類型時(shí)，SQL語句可能如下：Select*fromtablewhere字段名=’輸入的值’HTTP:///test.asp?name=1HTTP:///test.asp?id=1’，如果SQL查詢語句變成select*fromtablewhereid=1’，那么test.asp會出現(xiàn)運(yùn)行異常。HTTP:///test.asp?id=1and1=1，頁面運(yùn)行正常，且結(jié)果與HTTP:///test.asp?id=1運(yùn)行結(jié)果相同。HTTP:///test.asp?id=1and1=2，運(yùn)行出現(xiàn)異?；蛘吆虷TTP:///test.asp?id=1運(yùn)行結(jié)果不同。如果以上三步全部滿足，則一定存在SQL注入漏洞。第二種途徑是，對于一些通過POST的請求，很難直接通過瀏覽器URL修改參數(shù)來測試，可以通過一些工具的輔助達(dá)到測試目標(biāo)，例如，OWASP的ZAP和Fiddler工具（安裝Watch插件）。通過這些工具可以發(fā)動自動滲透測試，也可以攔截請求，通過修改請求消息中的參數(shù)值進(jìn)行測試。2.1.5SQL注入的預(yù)防措施預(yù)防SQL注入漏洞的主要措施如下所示：1）在服務(wù)器端要對所有的輸入數(shù)據(jù)驗(yàn)證有效性。2）在處理輸入之前，驗(yàn)證所有客戶端提供的數(shù)據(jù)，包括所有參數(shù)、URL和HTTP頭的內(nèi)容。3）驗(yàn)證輸入數(shù)據(jù)的類型、長度和合法的取值范圍。4）使用白名單驗(yàn)證允許的輸入字符而不是黑名單。5）如果危險(xiǎn)的字符必須作為輸入的一部分，在使用前必須轉(zhuǎn)義或者編碼。6）明確所有輸入的正確的字符集，如UTF-8。7）如果系統(tǒng)使用的是UTF-8擴(kuò)展字符集，在UTF-8解碼之后驗(yàn)證數(shù)據(jù)的有效性。8）不要動態(tài)組裝SQL語句。9）如果動態(tài)組裝SQL語句，確保在使用輸入的數(shù)據(jù)組裝SQL語句之前，對特殊字符進(jìn)行轉(zhuǎn)義。10）在使用第三方框架或者庫時(shí)，需要確認(rèn)是否有注入的問題，如果有注入問題，要做好預(yù)防措施，如Hibernate就有SQL注入問題，需要在調(diào)用之前將輸入的特殊字符進(jìn)行轉(zhuǎn)義。11）對于需要產(chǎn)生命令運(yùn)行的數(shù)據(jù)，保持盡量少的數(shù)據(jù)由外部輸入，例如，能傳參數(shù)的就不要穿命令行。12）以最小權(quán)限運(yùn)行。2.2跨站腳本攻擊簡介2.2.1跨站腳本攻擊漏洞定義用戶在瀏覽網(wǎng)站、使用通訊軟件或者是電子郵件的時(shí)候，會發(fā)現(xiàn)有很多鏈接存在其中，用戶通常都會點(diǎn)擊這些鏈接想看到自己想看的內(nèi)容。惡意攻擊者通過掌握這一習(xí)性，會把惡意代碼插入到鏈接中，用戶點(diǎn)擊鏈接，惡意代碼就能夠盜取用戶信息。為了避免用戶懷疑制作惡意鏈接的合法性，這些鏈接編碼會被惡意攻擊者用十六進(jìn)制編碼。這樣一個(gè)看似合法的頁面就生成了，其實(shí)頁面里包含了攻擊者制造的惡意腳本，用戶點(diǎn)擊之該鏈接的同時(shí)，私密信息就遭到了泄露。跨站腳本攻擊是一種網(wǎng)站應(yīng)用程序的安全漏洞攻擊，是腳本代碼注入的一種。它允許惡意用戶將惡意腳本代碼注入到網(wǎng)頁上，其他用戶在觀看網(wǎng)頁時(shí)，惡意腳本就會執(zhí)行。這類攻擊通常通過注入HTML或者JavaScript/VBScript腳本發(fā)動攻擊。攻擊成功后，攻擊者可以得到私密網(wǎng)頁內(nèi)容和Cookie等各種內(nèi)容。很多知名網(wǎng)站都曾經(jīng)受到過這種攻擊，如Twitter、Facebook、MySpace、Yahoo、新浪微博等。最近幾年XSS攻擊已經(jīng)超過了緩沖區(qū)溢出攻擊，成為最流行的攻擊方式[4]。2.2.2跨站腳本攻擊漏洞的分類及原理到目前為止，XSS(Cross-SiteScripting,跨站腳本攻擊)漏洞主要分成3類：反射式跨站腳本攻擊、存儲式跨站腳本攻擊和基于DOM的跨站腳本攻擊。下面介紹每種類型的特征以及原理：（1）反射式XSS也稱為非永久性XSS，是目前最流行的一種XSS攻擊。它經(jīng)常出現(xiàn)在服務(wù)器直接使用客戶端提供的數(shù)據(jù)（包括URL中的數(shù)據(jù)、HTTP協(xié)議頭的數(shù)據(jù)和HTML表單中提交的數(shù)據(jù)），而且沒有對數(shù)據(jù)進(jìn)行無害化處理。由于HTML文檔是一個(gè)扁平的連續(xù)結(jié)構(gòu)，同時(shí)其中還有一些控制語句，那么如果客戶提交的數(shù)據(jù)沒有經(jīng)過正確的HTML編碼而直接使用，就可能導(dǎo)致腳本注入。如果查詢的字符串中含有HTML而且沒有被正確處理，一個(gè)XSS攻擊就會發(fā)生。典型的反射式攻擊可以通過郵件或者一個(gè)中間的網(wǎng)站，誘餌是一個(gè)看起來沒有危害的指向一個(gè)信任站點(diǎn)的鏈接，其中包含有XSS攻擊向量。如果信任的網(wǎng)站沒有處理這個(gè)向量，客戶點(diǎn)擊這個(gè)鏈接就會導(dǎo)致瀏覽器執(zhí)行注入的腳本[5]。如圖2-3所示：圖2-3反射式XSS過程1）A訪問網(wǎng)站這個(gè)網(wǎng)站比較頻繁，A有登錄的登錄用戶名及登錄密碼并且還在這個(gè)網(wǎng)站上存儲了敏感數(shù)據(jù)，比如支付賬戶、支付密碼、收貨地址等信息。2）B發(fā)現(xiàn)這個(gè)網(wǎng)站上存在有反射式跨站腳本攻擊漏洞，他就通過這個(gè)網(wǎng)站存在反射式跨站腳本攻擊漏洞構(gòu)造了一個(gè)URL，然后通過郵件的方式發(fā)送給A，讓A通過點(diǎn)擊他構(gòu)造的URL來訪問3）A訪問B提供的URL并且登錄到。4）把含有嵌入的惡意攻擊的JavaSprint代碼返回結(jié)果發(fā)送給A。5）A接收到返回結(jié)果后，含有惡意攻擊的代碼在A的瀏覽器中被執(zhí)行，這個(gè)惡意代碼可以將A的會話Cookie在A不知情情況下發(fā)送給B控制的站點(diǎn)www.B。6）B可以從他控制的網(wǎng)站www.B中獲取A的會話Cookie。7）B使用他獲取的會話Cookie盜取A的個(gè)人信息，此時(shí)A還不知道自己的信息被竊取。（2）存儲式XSS也稱為永久性的XSS，它的危害更大。典型的例子就是在交友網(wǎng)站上，如果一個(gè)人在自己的信息上寫上一段腳本，如“自我介紹<script>windows.open(?yourcookie=document.cookie)</script>”，這個(gè)網(wǎng)站沒有對自我介紹的內(nèi)容進(jìn)行正確的編碼。當(dāng)網(wǎng)站的其他用戶看這個(gè)用戶的信息時(shí)，這個(gè)用戶將會得到所有看他的自我介紹的用戶會話Cookie。更嚴(yán)重的是，如果攻擊者的惡意代碼可以自我擴(kuò)散，特別是在社交網(wǎng)絡(luò)上，就會形成蠕蟲。早期的Samyworm就是一個(gè)典型的例子[6]。如圖2-4所示。圖2-4存儲式XSS過程1）B發(fā)現(xiàn)這個(gè)網(wǎng)站上存在存儲式跨站腳本攻擊漏洞，B向這個(gè)網(wǎng)站發(fā)送一條含有惡意的消息。2）接收消息并且存儲消息。3）A在瀏覽過程中發(fā)現(xiàn)這條消息，由于對這條消息好奇就點(diǎn)擊鏈接對這條消息的內(nèi)容進(jìn)行讀取。4）會把這條消息從原本存儲的地方提取出來給A查看。5）當(dāng)A讀取到這條消息后，消息中包含的惡意代碼就會在A當(dāng)前使用的瀏覽器上悄悄執(zhí)行。6）然后A的Cookie會被執(zhí)行的惡意代碼全部發(fā)送到B控制的網(wǎng)站上。7）B從他控制www.B這個(gè)網(wǎng)站上面獲取A的會話Cookie。8）這個(gè)時(shí)候，B就可以借助他獲取的A的Cookie劫持A的會話，冒充A。（3）基于DOM的XSS傳統(tǒng)意義上，XSS漏洞發(fā)生在由服務(wù)器產(chǎn)生并且發(fā)回到客戶端的頁面上。隨著Web2.0的出現(xiàn)，一種新型的XSS漏洞也浮出水面，它就是基于DOM的XSS?；贒OM的XSS發(fā)生在客戶端處理內(nèi)容的階段，發(fā)生在客戶端控制。基于DOM的XSS利用場景和反射式的XSS的原理基本一樣，不同的是：基于DOM的XSS在服務(wù)器端沒有辦法控制，必須在客戶端控制。2.2.3跨站腳本漏洞經(jīng)典案例及修改方法經(jīng)實(shí)例代碼：本次例子中都以輸入字符串是“XSSTest<&’/”>”<html><head><title>ForTest4.2.3HTMLbasedinjection</title><metahttp-equiv=”content-type”content=”text/html;charset=utf-8”></head><script>varsearchValue=<%=searchValue%>;</script><body><formname=”myForm”>您搜索的內(nèi)容是：<%=searchValue%>結(jié)果如下：<table><tr><td>Name</td><td>Address</td></tr><tr><tdid=”td1”><%=name%></script></td><tdid=”td2”><%=Address%></td></tr></table></form></body></html>在搜索“XSSTest<&’”>”之后，即使我們不知道這個(gè)源碼，也可以通過瀏覽器的查看源代碼菜單，猜測頁面的源代碼可能為：<html><head><title>ForTest4.2.3HTMLbasedinjection</title><metahttp-equiv=”content-type”content=”text/html;charset=utf-8”></head><script>varsearchValue=XSSTestxxxx;</script><body><formname=”myForm”>您搜索的內(nèi)容是：XSSTestxxxx結(jié)果如下：<table><tr><td>Name</td><td>Address</td></tr><tr><tdid=”td1”><%=name%></script></td><tdid=”td2”><%=Address%></td></tr></table></form></body></html>在頁面源碼中，搜索“XSSTest”，然后在看“<&’”>”這幾個(gè)字符的編碼是不是正確，如果不正確，再根據(jù)一些頁面源代碼結(jié)構(gòu)，構(gòu)造一些可能導(dǎo)致攻擊的字符串，進(jìn)行嘗試攻擊。常用的測試字符串如下：（1）：JavaSprint注入的代碼:“><script>alert(document.cookie)</script></script><script>alert(document.cookie)</script>（2）：HTML常用的注入代碼：<aherf=javascript:alert(1)>DEF</a><imgsrc=asdfonerror=alert(document.cookie)>更多測試字符串可以參考：/xss.html2.2.4跨站腳本漏洞的檢測方法以及檢測工具（1）手動檢測手動檢測，就是依靠手工輸入來檢測網(wǎng)頁是否有錯(cuò)誤，這種檢測主要是手工修改文本框（包括被隱藏的）或者URL中的參數(shù)，提交請求后，再在網(wǎng)頁中查找是否有修改自己的參數(shù)顯示，包括HTML和JavaSprint中，如果在HTML和JavaSprint中有，則看看編碼是不是正確，如果編碼不正確，那么就有可能有XSS問題。輸入的字符串也不能隨便選擇，需要選擇一些有特殊意義的字符，例如：<、>、&、’、”，輸入的字符串最好包括所有這些特殊字符，這樣才能看到每個(gè)字符的編碼是否正確。為了方便在頁面中查找，建議輸入一些容易查找的字符，例如使用“XSSTest<&’/”>“進(jìn)行測試，輸入“XSSTest<&’/”>“之后，在結(jié)果頁面上，查詢”XSSTest“，然后再看看每一個(gè)顯示“XSSTest<&’/”>“的地方是不是編碼正確。例如：在HTML標(biāo)簽中，如果</>編碼不正確，可能導(dǎo)致HTML注入類型的XSS；如果雙引號（”）編碼不正確，可能導(dǎo)致HTML的屬性被注入，也可能導(dǎo)致JavaSprint注入。（2）半自動檢測手工測試雖然簡單，即不停地嘗試各種參數(shù)，看看哪一個(gè)參數(shù)可能會引入問題。但是效率卻不是很高。因?yàn)橐粋€(gè)網(wǎng)頁可能有很多輸入項(xiàng)和輸出項(xiàng)，還有內(nèi)容是存儲在DB中的，素以測試量是很大的，而且頁面上還做了限制輸出框，也會導(dǎo)致一些測試用例無法使用。為了提高效率和測試覆蓋度，必須借助一些工具。半自動檢測主要借助一些檢測工具，這些檢測工具的基本原理是在本地啟動一個(gè)默認(rèn)端口是8080的代理服務(wù)器，把http://localhost:8080這個(gè)地址設(shè)置為瀏覽器的代理地址，然后通過配置工具的一些腳本，工具就可以完成自動測試，也可以通過捕捉請求和修改請求，來測試一些不可以直接測試的用例，特別是Post的一些請求，測試結(jié)果出來之后，還需要進(jìn)一步分析，排除錯(cuò)誤的用例。（3）全自動檢測全自動檢測，也是需要用戶參與分析的。全自動檢測根據(jù)是否需要運(yùn)行程序，不運(yùn)行程序的是靜態(tài)檢測，運(yùn)行程序的是動態(tài)檢測。1）靜態(tài)檢測:工具會根據(jù)事先制定的規(guī)則在不運(yùn)行程序的情況下自動分析源代碼，通過對比制定的規(guī)則來分析程序是否存在有威脅的源代碼。2）動態(tài)檢測：運(yùn)行程序模擬發(fā)送出請求，分析返回的響應(yīng)消息，查看有威脅的字符串有沒有出現(xiàn)在響應(yīng)消息中。2.2.5跨站腳本的預(yù)防措施（1）消除漏洞任何有關(guān)用戶的輸入信息都不要再輸出頁面上提供出來。（2）抵御漏洞1）所有的在頁面上的輸出都要編碼。2）使用一個(gè)統(tǒng)一的規(guī)則和庫做輸出編碼。3）只在輸入的地方做驗(yàn)證是不夠的，要在顯示的地方做輸出編碼。4）如果一個(gè)內(nèi)容要在多個(gè)地方輸出，需要在每一個(gè)地方便嗎，而且具體的編碼要根據(jù)環(huán)境的不同而不同。5）根據(jù)輸出的背景環(huán)境正確地做復(fù)合編碼。6）對于富文本框，使用白名單控制輸入而不是黑名單。2.3不正確的直接對象引用漏洞簡介2.3.1不正確的直接對象引用漏洞定義DOR(DirectObjectReference,直接對象引用)是指開發(fā)者將文件、路徑、數(shù)據(jù)庫記錄或者Key作為URL或表單的一部分，暴露給用戶的一個(gè)引用。攻擊者能夠操作直接對象引用去訪問一些他沒有權(quán)限的其他對象，除非訪問控制被恰如其分的檢查。所謂的不安全的直接對象引用，就是說，在引用對象時(shí)，訪問控制沒有做好，以至于某些用戶可以越過限制，訪問他不應(yīng)該訪問的信息。2.3.2不正確的直接對象引用漏洞原因一些在內(nèi)部實(shí)施的對象，比如文件、目錄、數(shù)據(jù)庫記錄等，這些對象都是不正確的對象引用中的“對象”。如果這些對象之一發(fā)現(xiàn)應(yīng)用程序URL（或表單參數(shù)）中一個(gè)引用被暴露出來,這時(shí)安全問題就會被觸發(fā)。因?yàn)檫@些直接引用的對象可以被黑客用來修改達(dá)到攻擊的目的，例如，在一個(gè)URL被提交之前，URL中的一個(gè)引用被黑客進(jìn)行參數(shù)修改，黑客修改參數(shù)的企圖是訪問一個(gè)未獲得授權(quán)的文件、目錄、或數(shù)據(jù)庫中的條目。在這種情況下如果網(wǎng)站的其他的授權(quán)檢查不被加強(qiáng)，黑客的企圖會成功。2.3.3不正確的直接對象引用漏洞經(jīng)典案例及修改方法經(jīng)典案例：舉一個(gè)訪問用戶信息的例子，通過UserID可以得到用戶的所有信息：http://www//userfo.do?ID=3。使用AccessReferenceMap，需要在處理的Action中添加代碼處理直接引用到非直接引用的匹配的操作。代碼如下：當(dāng)獲取用戶列表時(shí)，需要使用AccessReferenceMap產(chǎn)生非直接引用并且將其保護(hù)到對象中，同事也要保存在AccessReferenceMap中。<Userfouser;Collectioncoll;//保存顯示在UI中的非直接飲用//使用隨機(jī)訪問的引用mapAccessReferenceMapmap=newRandomAccessReferenceMap();//通過用戶的ID獲得非直接引用StringindirectReference=map.addDirectReference(user.getId());//將非直接引用保存到對象中，這需要對象的支持User.setIndirectReference(indirectReference);//增加對象到顯示的集合中coll.add(user);//存儲coll到對象request或者session中，然后發(fā)給UI當(dāng)獲取具體的用戶信息時(shí)，需要根據(jù)非直接引用獲得直接引用，然后去獲取具體的用戶信息：UserInfouser=null;StringindirectRef=request.GetIndirectRef();user=map.GetDirectReference(indirectRef);//這里需要處理拋出異常AccessControlException的情況//根據(jù)directRef也就是用戶ID去DB獲取具體的用戶的信息。如果一個(gè)用戶有很多文件，想一下添加一個(gè)結(jié)合的非直接引用到AccessReferenceMap中，可以使用AccessReferenceMap的update函數(shù)：setfileSet=newHashSet();fileSet.addAll(…);//添加引用（例如id、File）AccessReferenceMapmap=newAccessReferenceMap(fileSet);//將map存儲在安全的地方——例如sessionStringindRef=map.getIndirectReference(file1);Stringhref=”/esapi?file=”+indRef)從例子可以看出使用AccessReferenceMap需要在session中保存匹配的AccessReferenceMap的一個(gè)實(shí)例，保存在session中的好處就是不會有線程安全問題，并且很容易就可以獲得信息。如果map中保存的對象不多，可以確保session不會保存太多信息，如果map中的對象太多，會導(dǎo)致session比較臃腫、占用的內(nèi)存比較多，這個(gè)時(shí)候采用線程安全的map，保存在一個(gè)全局變量中，map的Key值可以使session的id，這樣做雖然解決了session臃腫的問題卻可能也帶來了性能上的問題?？傊绻鎯Φ膶ο蟛欢嗟脑?，放在session中是一個(gè)很好的選擇。2.3.4不正確的直接對象引用漏洞的檢測方法以及檢測工具不正確的對象引用對于網(wǎng)站來說不是什么異常行為，這個(gè)過程很難被檢測到，除非查看或者檢測日記。由于訪問信息對于系統(tǒng)來說并不是有害的操作，有的產(chǎn)品甚至還沒有對修改或刪除操作的記錄日志，這也就大大加大了檢測難度。與此同時(shí)，漏洞掃描器對這不正確的直接對象引用漏洞也不是很高效。最佳的方法只能是以下兩種：1）仔細(xì)檢查代碼中重要的參數(shù)，反復(fù)確認(rèn)其是否存在易于遭到利用和操縱的可能性。2）專業(yè)的滲透測試需要定期實(shí)施，來排除漏洞的存在。2.3.5不正確的直接對象引用漏洞的預(yù)防措施對于不正確的直接對象引用漏洞的防御措施主要有以下幾種：1）一些私密的對象引用做好防范措施，比如重要的關(guān)鍵字或者文件名，不要將其暴露給用戶查看。2）在允許訪問直接引用的對象之前做好授權(quán)驗(yàn)證。3）使用用戶級別或者Session級別的間接對象引用（比如用戶界面上下拉框中選項(xiàng)對應(yīng)簡單數(shù)字而不是對象的數(shù)據(jù)庫鍵值，界面數(shù)字與對象鍵值之間的對應(yīng)關(guān)系在用戶級別或session級別維護(hù)。）2.4偽造跨站請求漏洞簡介2.4.1偽造跨站請求漏洞定義偽造跨站請求通?？s寫為CSRF(Cross-siteRequestForgery，偽造跨站請求)，也被稱為“oneclickattack”或者sessionriding，通常縮寫為CSRF或者XSRF，是一種對網(wǎng)站的惡意利用。盡管聽起來像跨站腳本（XSSS），但是它與XSS非常不同，并且攻擊方式幾乎相左。XSS利用站點(diǎn)內(nèi)的信任用戶（受害者），而CSRF通過偽裝來自受信任的用戶的請求來利用受信任網(wǎng)站[7]。通過社會工程學(xué)的手段（如通過電子郵件發(fā)送一個(gè)鏈接）來蠱惑受害者進(jìn)行一些敏感性的操作，如修改密碼、修改E-mail、轉(zhuǎn)賬等，而受害者還不知道他已經(jīng)上當(dāng)。CSRF的破壞力依賴于受害者的權(quán)限。如果受害者只是個(gè)普通用戶，則一個(gè)成功的CSRF攻擊會危害用戶的數(shù)據(jù)以及一些功能；如果受害者是具有管理員權(quán)限，則一個(gè)成功的CSRF攻擊甚至?xí){到整個(gè)網(wǎng)站的安全。2.4.2偽造跨站請求漏洞產(chǎn)生的原因及過程舉例解釋攻擊原理如圖2-5所示。圖2-5CSRF攻擊過程1）A登錄一個(gè)金融網(wǎng)站XXX準(zhǔn)備進(jìn)行網(wǎng)上支付。2）B知道這個(gè)金融網(wǎng)站XXX，并且意識到這個(gè)站點(diǎn)的轉(zhuǎn)賬功能有CSRF漏洞，B在發(fā)表一個(gè)blog，這個(gè)blog支持img自定義功能，B插入這么一行HTML代碼：<imgsrc=”http://XXX/transferMoney.jsp?to=B&cash=5000”.。width=”1”height=”1”border=”0”>。3）A在自己的瀏覽器上打開了另一個(gè)標(biāo)簽頁讀到了這個(gè)blog。4）于是A的賬戶就向B的賬戶轉(zhuǎn)賬5000元，但是A卻絲毫不知道。2.4.3偽造跨站請求漏洞經(jīng)典案例及修改方法經(jīng)典案例：案例中B先自己訪問XXX中的轉(zhuǎn)賬功能，發(fā)送HTTP請求如下：POST/transferMoney.jspHttp/1.1Host:XXX:80User-Agent:Mozilla/5.0(WindowsNT5.1;rv:9.0.1)Gecko/20100101Firefox/9.0.1Accept:Text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:en-us,en;q=0.7,zh-cn;q=0.3Accept-Encoding:gzip,deflateAccept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection:keep-aliveReferer:http://localhost:80/transferMoney.jspCookie:JSESSIONID=17FA8B1D4C071101B6B11D7F8CD22566Content-Type:application/x-www-form-urlencodedContent-Length:16To=B&cash=5000這個(gè)請求的返回如下：Http/1.1200okContent-Type:Text/html;charset=ISO-8859-1Content-Length:238Date:sun,05Feb201212:01:37GMTServer:hahafakeserverTransfertoBcash:5000然而B發(fā)現(xiàn)如果向同一個(gè)網(wǎng)址發(fā)送GET請求也能成功，如下所示：GET/transferMoney.jsp?to=B&&cash=5000HTTP/1.1User-Agent:Mozilla/5.0(WindowsNT5.1;rv:9.0.1)Gecko/20100101Firefox/9.0.1Accept:Text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:en-us,en;q=0.7,zh-cn;q=0.3Accept-Encoding:gzip,deflateAccept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection:keep-aliveCookie:JSESSIONID=17FA8B1D4C071101B6B11D7F8CD22566這個(gè)GET請求的返回與POST請求的返回一樣：Content-Type:Text/html;charset=ISO-8859-1Content-Length:238Date:sun,05Feb201212:01:37GMTServer:hahafakeserverTransfertoBcash:5000B決定利用網(wǎng)站的這個(gè)漏洞來攻擊A。于是B構(gòu)造了下面的這個(gè)URL，準(zhǔn)備從A的賬戶中轉(zhuǎn)走5000元到他的賬戶：http://XXX/transferMoney.jsp?to=B&cash=5000。為了使得上面的URL生效，B必須誘導(dǎo)A點(diǎn)擊這個(gè)鏈接。最常見的方法就是給A發(fā)送一個(gè)郵件然后引誘A訪問這個(gè)blog并且訪問這個(gè)鏈接。采用這種方法就是轉(zhuǎn)賬成功，A也會發(fā)現(xiàn)，于是修改了原來的腳本：<imgsrc=”http://XXX/transferMoney.jsp?to=B&cash=5000”.。width=”1”height=”1”border=”0”>2.4.4偽造跨站請求的檢測方法以及檢測工具（1）手工檢測1）用受害者身份登錄，然后進(jìn)行某個(gè)重要功能的操作，假設(shè)是增加一個(gè)新用戶test1，它具有admin角色，URL是：http://localhost.adduser?username=test1&r-ole=administator。2）攻擊者構(gòu)造這個(gè)重要操作的URL，比如寫成<imgsrc=http://localhost/addu-ser?username=test1&role=administatorwidth=”1”height=”1”border=”0”/>。如果該操作是POST請求，可以利用CSRFRedirector來模擬一個(gè)GET請求。3）在確保受害者登錄的情況下，讓受害者點(diǎn)擊攻擊攻擊者構(gòu)造的URL。4）檢查結(jié)果：服務(wù)器是否執(zhí)行了你的請求，如果執(zhí)行了，則說明那個(gè)重要功能存在著CSRF漏洞。（2）半自動檢測CSRFTester是一款CSRF檢測工具，可以從/imag-es/0/08/CSRFTester-1.0zip進(jìn)行下載。2.4.5偽造跨站請求的預(yù)防措施防止CSRF通常需要列入每個(gè)HTTP請求中的一個(gè)不可預(yù)知的令牌。這些令牌，至少，每個(gè)用戶會話應(yīng)該是唯一的。主要措施如下所示：1）最佳選擇是獨(dú)有的令牌包含在一個(gè)隱藏字段中，這將使得這些值放在要發(fā)送的HTTP報(bào)體的請求的值中，避免包含在URL中，因?yàn)檫@樣就直接暴露了。2）獨(dú)特的令牌也可以包含在URL中，或URL參數(shù)中，然而這種安排的URL有暴露給攻擊者的風(fēng)險(xiǎn)，從而損害秘密令牌。3）OWASP的CSRF防護(hù)令牌可以自動包括在JavaEE、.NET或PHP應(yīng)用程序中。OWASP的ESAPI包括CSRF的方法，開發(fā)人員可以使用它來防止這種漏洞。4）要求用戶重新進(jìn)行身份驗(yàn)證，證明他們是一個(gè)合法用戶（例如，通過一個(gè)CAPTCHA），也可以防止CSRF。2.5未驗(yàn)證的重定向和轉(zhuǎn)發(fā)漏洞簡介2.5.1未驗(yàn)證的重定向和轉(zhuǎn)發(fā)漏洞定義URL重定向和轉(zhuǎn)發(fā)，是通過一些存在于服務(wù)器上面的特殊設(shè)置，訪問當(dāng)前域名的用戶被引導(dǎo)，頁面跳轉(zhuǎn)到另一個(gè)提前制定好的網(wǎng)絡(luò)地址，即將一個(gè)域名指向另一個(gè)已經(jīng)存在的站點(diǎn)，或者講一個(gè)頁面引導(dǎo)到另一個(gè)頁面。這種頁面之間的轉(zhuǎn)換方式有兩種方式：隱藏路徑和不隱藏路徑.URL轉(zhuǎn)發(fā)通常都采用隱藏路徑的方式，URL重定向一般都采用不隱藏路徑的方式。2.5.2未驗(yàn)證的重定向和轉(zhuǎn)發(fā)產(chǎn)生的原因及過程URL轉(zhuǎn)發(fā)這個(gè)過程就和三角借貸一樣，瀏覽器沒有錢，就寫信找A.jsp借錢，但是A.jsp沒有錢，于是A.jsp找B.jsp說自己錢不夠，讓B.jsp來處理這件事情，B.jsp將所有的錢湊夠，然后再將這筆錢“郵寄”給瀏覽器?？梢钥闯?，瀏覽器發(fā)信向A.jsp借錢，結(jié)果從B.jsp拿到了這筆錢。而且對于瀏覽器來說，它也不知道是從哪里拿到的錢，但結(jié)果如瀏覽器想的那樣，它借到錢了。瀏覽器感覺A.jsp是一個(gè)好人，借錢總是能借到。對于瀏覽器來說，寫了一封信，就可以得到答復(fù)和借到錢。具體過程如圖2-6所示：圖2-6URL轉(zhuǎn)發(fā)過程重定向是服務(wù)器對于瀏覽器的請求直接做出響應(yīng)，響應(yīng)的結(jié)果就是告訴瀏覽器去另外一個(gè)地址請求所需要的信息，然后，瀏覽器在訪問另一個(gè)URL得到具體的信息。還以上面的借錢例子來說，這個(gè)過程就變成：瀏覽器寫信向借錢，說自己沒有錢，請找借錢，瀏覽器又寫信向借錢，把錢匯給了瀏覽器，在本次借錢的過程中，雖然沒從那借到錢，但是給它說了一個(gè)可以借到錢的地方。具體流程如圖2-7所示。圖2-7重定向流程圖2.5.3未驗(yàn)證的重定向和轉(zhuǎn)發(fā)漏洞經(jīng)典案例及修改方法經(jīng)典案例：用戶想要訪問的URL如下：/redirect.html?url=/external_page.html用戶看到這個(gè)URL是訪問的一個(gè)URL，是一個(gè)知名的站點(diǎn)，用戶人為這個(gè)URL肯定是訪問的。攻擊者利用這一點(diǎn)，修改URL為：/redirect.html?url=/external_page.ht-ml用戶看不到這個(gè)URL的域名是，他經(jīng)常訪問這個(gè)網(wǎng)站，所以相信這個(gè)URL應(yīng)該沒有惡意。其實(shí)他訪問的是一個(gè)攻擊者事先準(zhǔn)備的惡意網(wǎng)站。這種URL是很簡單的，可以通過查看整個(gè)URL是否跳轉(zhuǎn)到其他的危險(xiǎn)站點(diǎn)。攻擊者想到一些方法使得跳轉(zhuǎn)的URL比較模糊，可以通過十六進(jìn)制編碼將域名編碼如下：%77%77%77%2e%65%76%69%6c%65%78%61%6d%70%6c%65%2e%63%6f%6d對于這個(gè)URL一般人很難看出它到底是一個(gè)怎樣的URL。如果挑戰(zhàn)到登錄頁面的URL被攻擊者修改，然后發(fā)送給一個(gè)用戶去訪問，那么，攻擊者就可以得到用戶的用戶名和密碼。同樣以前面的登錄案例為例：/login.do?return_url=/userinfo.jsp?u=1一個(gè)惡意的攻擊者可能將URL修改為：/login.do?return_url=/login.do。用戶登錄成功之后，仍然會顯示一個(gè)登錄頁面，只不過這次是/的登錄頁面，而且頁面的整體風(fēng)格都一樣，并且提示用戶輸入的用戶名或者密碼錯(cuò)誤，用戶以為登錄失敗就會重新輸入一次，這次用戶名和密碼就會被提交到/而不是，攻擊者控制著/這個(gè)網(wǎng)站，也就可以得到用戶名和密碼。如果攻擊者修改的URL是下面的URL：/login.do?return_url=/manageruser.jsp，就有可能直接跳轉(zhuǎn)到管理用戶的界面。即使使用相對路徑/lo-gin.do?return_url=/userinfo.jsp，也可以將其修改為：/login.do?return_url=admin.jsp繞過認(rèn)證。2.5.4未驗(yàn)證的重定向和轉(zhuǎn)發(fā)的檢測方法以及檢測工具可以通過spider工具訪問站點(diǎn)，查看響應(yīng)消息中是否有以300~307開頭的響應(yīng)消息，特別是301和302。如果存在，就說明有重定向存在，然后再檢查是否有參數(shù)用作重定向的目標(biāo)或者作為重定向目標(biāo)的一部分。如果有，修改參數(shù)的目標(biāo)URL，再觀察這個(gè)請求是否被重定向到新的目標(biāo)，如果重定向到這個(gè)修改之后的目標(biāo)，說明服務(wù)器端沒有對重定向之后的目標(biāo)進(jìn)行驗(yàn)證，可能存在問題。如果不能跳轉(zhuǎn)到其他網(wǎng)站，嘗試跳轉(zhuǎn)網(wǎng)站內(nèi)部其他的頁面，特別是一些管理頁面，防止通過修改URL參數(shù)繞過訪問控制。2.5.5未驗(yàn)證的重定向和轉(zhuǎn)發(fā)漏洞的預(yù)防措施在如下方式中可以做到安全使用重定向和轉(zhuǎn)發(fā)：1）僅僅避免使用重定向和轉(zhuǎn)發(fā)。2）如果使用，不涉及用戶參數(shù)計(jì)算目標(biāo)，這樣通常是可以的。3）如果不能避免目標(biāo)參數(shù)，確保所提供的價(jià)值是有效的、授權(quán)的用戶。建議任何此類目標(biāo)參數(shù)映射值，而不是實(shí)際的URL或者URL的一部分，并且該服務(wù)器端代碼可以翻譯這種映射到目標(biāo)URL。應(yīng)用程序可以使用ESAPI覆蓋的sendRedirect（）方法，以確保所有重定向目的地是安全的。避免這種缺陷是極為重要的，因?yàn)樗鼈兪蔷W(wǎng)絡(luò)釣魚者通過調(diào)到用戶最喜愛的目標(biāo)來試圖獲得用戶的信任。2.6安全配置錯(cuò)誤漏洞簡介2.6.1安全配置錯(cuò)誤漏洞定義攻擊者訪問默認(rèn)的賬戶、沒有用過的頁、未打補(bǔ)丁的漏洞、不受保護(hù)的文件和目錄等，來得到未經(jīng)授權(quán)的訪問權(quán)限或者系統(tǒng)的信息。這種漏洞可以發(fā)生在任何級別的應(yīng)用程序堆棧。2.6.2安全配置錯(cuò)誤漏洞的威脅和后果1）為攻擊者提供一些系統(tǒng)數(shù)據(jù)或功能未經(jīng)授予的訪問權(quán)限。2）有時(shí)候會導(dǎo)致整個(gè)系統(tǒng)的損壞。2.6.3安全配置錯(cuò)誤的檢測方法以及檢測工具（1）Tomcat/Apache1）Tomcat必須以專用的沒有特權(quán)的用戶賬號和組運(yùn)行。2）賬號不能允許執(zhí)行交互式Shell命令或者直接登錄，但可以通過sudo切換。3）用戶和組的名字包含有服務(wù)或者組件的名字，如tomcat/tomcat。4）Tomcat的目錄樹必須被Tomcat服務(wù)的賬號擁有。5）應(yīng)用程序的目錄樹必須配置限制的文件訪問權(quán)限，如配置文件可以設(shè)置權(quán)限400只讀、日志可以設(shè)置為300可寫。6）Tomact運(yùn)行的版本必須是打了所有安全補(bǔ)丁的版本。7）SHUTDOWN命令和端口必須被修改。8）Tomcat提供的默認(rèn)的例子相關(guān)的路徑和文件必須被刪除。9）Tomcat管理員的默認(rèn)密碼必須被修改。10）響應(yīng)消息的Server頭和出錯(cuò)信息不能顯示Tomcat的版本信息和系統(tǒng)信息。11）關(guān)閉Tomcat的路徑列舉功能。12）Tomcat的默認(rèn)錯(cuò)誤頁面必須被替換。13）在Tomcat配置文件中禁用不安全的HTTP方法，如TRACE、OPTIONS。只啟用安全的HTTP方法，如GET、POST。14）Apache的歡迎頁面（/etc/httpd/conf.d/welcome.conf）必須被刪除。15）etc/httpd/conf.d/ssl.conf必須被刪除。16）應(yīng)用程序和管理程序使用不同的端口。17）管理的控制臺必須使用SSL協(xié)議。18）管理控制臺服務(wù)必須被限定在管理的區(qū)域才能訪問。（2）數(shù)據(jù)庫1）默認(rèn)的用戶名和密碼必須修改。2）訪問數(shù)據(jù)庫用戶的密碼必須符合一定復(fù)雜度。3）訪問數(shù)據(jù)庫的用戶要賦予所需要的最少權(quán)限，如增加表、刪除表、修改表等權(quán)限不是必要的權(quán)限，就不需要給訪問數(shù)據(jù)庫的用戶。（3）應(yīng)用程序1）啟動應(yīng)用程序的系統(tǒng)用戶必須是專用的、沒有系統(tǒng)級別特權(quán)的用戶和組。2）沒有用的文件必須從應(yīng)用程序上刪除，如備份文件、臨時(shí)文件等。3）在部署之前，刪除沒有用的功能和測試代碼。4）配置文件中沒有默認(rèn)的用戶名和密碼。5）配置文件中沒有明文的密碼和密鑰。6）應(yīng)用程序不能再產(chǎn)品環(huán)境上以Debug或者開發(fā)模式運(yùn)行。7）應(yīng)用程序必須使用JRE的JDK運(yùn)行，而不是JavaSDK。8）不要在robot.txt中泄露目錄結(jié)構(gòu)。（4）操作系統(tǒng)1）系統(tǒng)所有用戶的密碼都必須符合一定的復(fù)雜度。2）當(dāng)前在用的操作系統(tǒng)沒有已知的漏洞。3）禁止啟用不用的服務(wù)，例如，F(xiàn)TP、Telnet、SMTP等。4）要啟用ASLR和DEP的選項(xiàng)。（5）編譯器1）使用的編譯器已經(jīng)更新了所有的安全補(bǔ)丁。2）開啟所有的編譯告警。3）啟用堆棧執(zhí)行保護(hù)編譯選項(xiàng)。4）啟用堆棧溢出檢測編譯選項(xiàng)。5）啟動動態(tài)地址載入編譯選項(xiàng)。2.6.4安全配置錯(cuò)誤漏洞的預(yù)防措施安全配置可能在各個(gè)級別(platform/webserver/applicationserver/database/framework/customcode)出錯(cuò)，開發(fā)人員需要同網(wǎng)絡(luò)管理人員共同合作來確保合理配置，具體措施如下所示：1）系統(tǒng)的安全配置必須定期進(jìn)行驗(yàn)證。2）對所有組件都必須保證安裝了最新的補(bǔ)丁。3）對所有你做的安全配置進(jìn)行記錄。4）使用專業(yè)自動化掃描工具定期檢查安全漏洞。2.7敏感數(shù)據(jù)暴露漏洞簡介2.7.1敏感數(shù)據(jù)暴露漏洞定義許多Web應(yīng)用沒有正確地保護(hù)敏感數(shù)據(jù)，例如信用卡卡號、稅號、身份認(rèn)證證書等。攻擊者可以通過偷竊、更改這種弱保護(hù)的數(shù)據(jù)，以進(jìn)行信用卡詐騙、身份竊取、或者其他犯罪活動。2.7.2敏感數(shù)據(jù)暴露漏洞的成因及威脅后果考慮誰會獲得你的敏感數(shù)據(jù)或者敏感數(shù)據(jù)備份的可能性,這些包括敏感數(shù)據(jù)源，傳輸中的數(shù)據(jù)甚至在你的顧客的瀏覽器中。包括外部和內(nèi)部的威脅敏感數(shù)據(jù)。例如：銀行卡卡號、用戶地址、登錄密碼等，這些敏感的信息都應(yīng)該進(jìn)行保護(hù)，對于這些敏感數(shù)據(jù)，以下幾點(diǎn)做不到就會引起數(shù)據(jù)的暴露：1）這些信息和這些信息的備份不管在什么地方長期存儲都需要進(jìn)行加密。2）這些數(shù)據(jù)在傳輸時(shí)要加密，理想狀況下，內(nèi)部傳輸和外部傳輸都需要加密。3）所有的加密都應(yīng)該使用復(fù)雜的加密方式，防止信息的暴露。4）正確的瀏覽器指令和頭部信息保護(hù)敏感信息或者是發(fā)送到瀏覽器。2.7.3敏感數(shù)據(jù)暴露攻擊舉例情形1：一個(gè)應(yīng)用程序使用一個(gè)自動的數(shù)據(jù)庫加密技術(shù)對信用卡號在數(shù)據(jù)庫中進(jìn)行加密。然而這意味著在取回的時(shí)候會自動的解密，允許一個(gè)SQL注入的缺陷在明文中去取回信用卡號。此類系統(tǒng)應(yīng)該使用公共密鑰加密的信用卡號碼，并只允許后端應(yīng)用程序?qū)ζ溥M(jìn)行解密用私鑰。情形2：一個(gè)簡單的站點(diǎn)不會對所有的已經(jīng)驗(yàn)證過的頁面使用SSL。攻擊者僅僅監(jiān)視網(wǎng)絡(luò)中的傳輸（例如一個(gè)開放的無線網(wǎng)絡(luò)），竊取用戶的會話Cookie。攻擊者然后，攻擊者重放這個(gè)cookie劫持用戶的會話，訪問他們的私人數(shù)據(jù)。情形3：密碼數(shù)據(jù)庫采用未加料的哈希存儲每個(gè)人的密碼。一個(gè)文件的上傳缺陷允許攻擊者去取回密碼文件。未加料的哈希可以暴露預(yù)先計(jì)算好的哈希的彩虹表。2.7.4敏感數(shù)據(jù)暴露漏洞的預(yù)防措施不安全的加密，SSL使用和數(shù)據(jù)保護(hù)的完整的危險(xiǎn)遠(yuǎn)遠(yuǎn)超出了前10名。這就是說，所有敏感數(shù)據(jù)，至少要做到以下幾點(diǎn)：1）考慮你要保護(hù)的數(shù)據(jù)的威脅來自哪里（是內(nèi)部人員的攻擊還是外部使用者），確保加密所有的敏感數(shù)據(jù)源和傳輸中的數(shù)據(jù)來抵抗這些威脅。2）不要存儲不必要的敏感數(shù)據(jù)并且盡快丟棄，你沒有的數(shù)據(jù)就不會被竊取。3）確保使用強(qiáng)大標(biāo)準(zhǔn)的加密算法和密鑰，并且恰當(dāng)?shù)轿坏墓芾砻荑€。4）確保密碼在存儲時(shí)已經(jīng)被專門設(shè)計(jì)的密碼保護(hù)算法加密，例如bcrypt、PBKDF2、scrypt。5）禁用“自動完成”的形式，收集敏感數(shù)據(jù)，并禁用緩存頁面顯示敏感數(shù)據(jù)。/html/itweb/20130921/128881_128884_128882.htm2.8使用已知易受攻擊的組件漏洞簡介2.8.1使用已知易受攻擊的組件漏洞定義許脆弱的組件是常見的，一些脆弱的組件(如?？蚣軒?可以利用自動化工具被識別。攻擊者可以識別出脆弱的組件借助掃描工具或者是手工分析。根據(jù)他們識別出的脆弱的組件從而定義了需要以及執(zhí)行攻擊的漏洞。2.8.2使用已知易受攻擊的組件漏洞的成因及威脅后果一些脆弱部件（例如，框架庫）可以利用自動化工具被識別，擴(kuò)大的威脅超越代理池中有針對性的攻擊，包括混亂的參與者。成因：1）沒有經(jīng)過授權(quán)的功能的的導(dǎo)航?jīng)]能夠在UI中顯示出來。2）進(jìn)行了錯(cuò)誤的授權(quán)和對授權(quán)檢查的忽略。3）服務(wù)器上是否存在被攻擊者依賴信息沒有被檢查出來，給攻擊者提供攻擊的機(jī)會。2.8.3使用已知易受攻擊的組件漏洞攻擊舉例組件幾乎始終運(yùn)行應(yīng)用程序的全部特權(quán)，所以在任何組件中的缺陷可以是嚴(yán)重的，下面的兩個(gè)易損組件在2011年被下載220萬次。1）ApacheCXFAuthenticationBypass--未能通過提供身份令牌，攻擊者可以調(diào)用任何Web服務(wù)的完整權(quán)限。2）SpringRemoteCodeExecution--在Spring表達(dá)式語言的濫用允許攻擊者執(zhí)行任意代碼、有效地接管服務(wù)器。當(dāng)這兩個(gè)組件被應(yīng)用程序的用戶直接的訪問時(shí)，每個(gè)應(yīng)用程序使用這些脆弱的庫是容易受到攻擊。其它脆弱的庫，在應(yīng)用程序中更深，可能難以利用。2.8.4使用已知易受攻擊的組件漏洞的預(yù)防措施其中一個(gè)選項(xiàng)是不使用你沒有寫的組件。但實(shí)際上，處理這種漏洞的最佳方式是讓組件都更新到最新的狀態(tài)。軟件項(xiàng)目中應(yīng)該有地方做如下事情：1）正在使用的組件、版本、依賴能夠被正確地被識別出來。2）公共數(shù)據(jù)庫中、項(xiàng)目的郵件列表、安全郵件列表的組件需要更新到最新的狀態(tài)，并且監(jiān)視它們的安全性是否出現(xiàn)差錯(cuò)。3）管理組件的使用需要制定一份安全的策略用來規(guī)范，如需要一定的軟件開發(fā)實(shí)踐，通過安全測試，和可接受的許可證。2.9缺少功能層面的訪問控制漏洞簡介2.9.1缺少功能層面的訪問控制漏洞定義功能級別權(quán)限控制一般是卸載代碼中或者通過程序的配置文件夾完成，但是開發(fā)者經(jīng)常忘記添加一些功能權(quán)限控制代碼，所以導(dǎo)致了缺少功能層面的訪問控制。授權(quán)系統(tǒng)的用戶的攻擊者僅僅改變URL或者是一個(gè)特殊函數(shù)的參數(shù)就可以攻擊。2.9.2缺少功能層面的訪問控制漏洞攻擊過程缺少功能層面的訪問控制漏洞是攻擊者強(qiáng)制瀏覽到目標(biāo)URL上，一個(gè)未經(jīng)授權(quán)的用戶可以訪問用戶界面以及管理界面，這就是一種缺陷，這種缺陷可能指引攻擊者去非法攻擊更多的管理員頁面來獲取他們想要的利益。其攻擊過程如圖2-8所示。圖2-8缺少功能層面訪問控制攻擊過程1）攻擊者注意到URL表明他的角色/user/getAccounts2）他修改它到另一個(gè)目錄(角色)/admin/getAccounts,或/manager/getAccounts3）攻擊者可以看到不只是他們自己的帳戶2.9.3缺少功能層面的訪問控制攻擊舉例情形1：簡單的攻擊僅僅強(qiáng)制瀏覽到目標(biāo)URLs。下列的URLs需要授權(quán)，管理員的權(quán)利也需要訪問“admin_getappinfo”頁面。/app/getappInfo/app/admin_getappInfo如果一個(gè)未授權(quán)的用戶能夠訪問這兩個(gè)的任意一個(gè)頁面，這就是一個(gè)缺陷。如果一個(gè)授權(quán)的用戶但是不是管理員也能夠訪問“admin_getappinfo”頁面，這也是一個(gè)缺陷，這些缺陷可能指引攻擊者去非法攻擊更多的管理員頁面。情形2：一個(gè)頁面提供一個(gè)action的參數(shù)來指定被調(diào)用函數(shù)，不同的actions需要不同的角色，如果不執(zhí)行這些角色，那就是一個(gè)缺陷。2.9.4缺少功能層面的訪問控制漏洞的預(yù)防措施針對缺少功能層面的訪問控制漏洞的預(yù)防主要有以下幾點(diǎn)：1）不要hardcode權(quán)限控制，需要建立一種可以比較容易更新和監(jiān)測權(quán)限控制的機(jī)制。2）默認(rèn)拒絕所有訪問，訪問任何功能都需要被賦予特定的權(quán)限。3）如果某功能在一個(gè)workflow中，需要確認(rèn)所有的前提條件都在正確的狀態(tài)，然后允許訪問該功能。/html/itweb/20130921/128881_128884_128882.htm(har-dcode意思是在代碼中寫死)/leonhughes/article/details/4712792你的應(yīng)用程序應(yīng)該有一致的、易于分析的、能被所有的業(yè)務(wù)功能調(diào)用的授權(quán)模塊，通常情況下，這種保護(hù)是由外部應(yīng)用程序代碼的一個(gè)或多個(gè)組件提供：1）考慮配額管理的過程，并確保您可以輕松地更新和審核。不要硬編碼。2）應(yīng)當(dāng)拒絕所有訪問默認(rèn)情況下的強(qiáng)制執(zhí)行機(jī)制，需要明確授予特定角色訪問每個(gè)函數(shù)。3）如果是參與工作流中的檢查的功能，確保所有允許訪問的條件都處于正常狀態(tài)。2.10錯(cuò)誤的會話認(rèn)證和會話管理漏洞簡介2.10.1錯(cuò)誤的會話認(rèn)證和會話管理漏洞定義錯(cuò)誤的認(rèn)證和會話管理，簡單來說，就是我們訪問HTTP時(shí)的用戶名和密碼被惡意攻擊者竊聽了，也可能是我們的會話，攻擊者獲取sessionID，然后攻擊者冒充我們訪問HTTP[8]。因?yàn)闊o狀態(tài)這一特性是HTTP本身的屬性，所以HTTP每次訪問都是帶有個(gè)人憑證來進(jìn)行訪問請求的，身份認(rèn)證的結(jié)果往往是獲得一個(gè)令牌，通常放在cookie中，之后對用戶的識別根據(jù)這個(gè)授權(quán)的令牌進(jìn)行識別，而不需要每次都要登錄。SessionID的作用是用來跟蹤狀態(tài)，但是在網(wǎng)絡(luò)上監(jiān)聽sessionID又是一件很容易的事情，結(jié)果就造成攻擊者通過監(jiān)聽sessionID來達(dá)到他們想要進(jìn)行的攻擊[8]。2.10.2錯(cuò)誤的會話認(rèn)證和會話管理的成因及威脅后果錯(cuò)誤的會話認(rèn)證和會話管理漏洞的攻擊過程如圖2-9所示。圖2-9會話攻擊過程1）攻擊者B用一個(gè)合法的用戶身份登錄。2）服務(wù)器與B建立了一個(gè)會話，sessionid為1234567。3）B構(gòu)造了一個(gè)URL：/login.jsp?sessionid=1234567，發(fā)給了受害者A。4）A不小心打開鏈接登錄。5）A輸入了她的用戶名和密碼，此時(shí)，sessionid被B設(shè)置為1234567。6）B只需要輸入/login.jsp?sessionid=1234567，就可以看到A的個(gè)人信息了，因?yàn)榇藭r(shí)sessionid就代表了A。漏洞成因：在用戶進(jìn)入登錄頁面，但還未登陸時(shí)，就已經(jīng)產(chǎn)生了一個(gè)session，用戶輸入信息，登錄以后，session的ID不會改變，也就是說還是以前的那個(gè)session（事實(shí)上session也確實(shí)不會改變，因?yàn)闆]有建立新的session，原來的session也沒有被銷毀）。很多人只是讓會話的Invalidate沒有用（request.getSession().invalidate();），是因?yàn)閕nvalidate方法不是真正的將session銷毀，只是將session中的內(nèi)容清空，所以當(dāng)invalidate以后再新建session，新建的session其實(shí)不是新的，只是將之前的session重新啟用了。于是session的ID不變就不奇怪了。只有Cookie失效掉，才能換成新的sessionid。2.10.3錯(cuò)誤的會話認(rèn)證和會話管理攻擊舉例假設(shè)URL重寫被機(jī)票預(yù)訂應(yīng)用程序所支持，并且可以把會話ID寫在URL中：/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?d-est=Hawaii一個(gè)在此站點(diǎn)驗(yàn)證通過的用戶想讓他的朋友知道這筆交易。他將上面的鏈接通過郵件發(fā)送給他的朋友，但是不知道他會泄露自己的會話ID。當(dāng)他的朋友使用這個(gè)鏈接時(shí)，會使用他的會話和信用卡。應(yīng)用的超時(shí)事件沒有被適當(dāng)?shù)脑O(shè)置。用戶使用一個(gè)公共電腦訪問站點(diǎn)。在沒有點(diǎn)擊注銷登錄的情況下，僅僅管理了瀏覽器并且離開。攻擊者在一個(gè)小時(shí)后使用同樣的瀏覽器，這個(gè)瀏覽器認(rèn)證通過。解決方法：在登錄頁面上加上一段代碼：request.getSession().invalidate();//清空sessionif(request.getCookies()!=null){Cookiecookie=request.getCookies()[0];//獲取cookiecookie.setMaxAge(0);//讓cookie過期}2.10.4錯(cuò)誤的會話認(rèn)證和會話管理漏洞的預(yù)防措施（1）我們要整體審視我們的架構(gòu)1）認(rèn)證機(jī)制本身必須是簡單、集中和標(biāo)準(zhǔn)化的；2）使用容器提供給我們的標(biāo)準(zhǔn)sessionid；3）確保在任何時(shí)候用SSL來保護(hù)我們的密碼和sessionid。（2）驗(yàn)證認(rèn)證的實(shí)現(xiàn)機(jī)制1）檢查SSL的實(shí)現(xiàn)方法；2）驗(yàn)證所有與認(rèn)證相關(guān)的函數(shù)；3）確?！白N登錄”的動作能夠關(guān)閉所有對話；4）使用OWASP和WebScrab來測試你的應(yīng)用。3Web應(yīng)用程序安全漏洞知識庫設(shè)計(jì)與實(shí)現(xiàn)3.1需求分析3.1.1項(xiàng)目背景 由于互聯(lián)網(wǎng)的飛速發(fā)展，人們的生活已經(jīng)離不開互聯(lián)網(wǎng)。當(dāng)今Web許多安全方面頻頻遭受攻擊，Web漏洞解決問題已經(jīng)迫在眉睫。為了人們的上網(wǎng)安全，整理分析OWASPTOP10漏洞進(jìn)行分析整理。分析這些經(jīng)典的漏洞，旨在幫助程序員提升他們的編碼安全意識，加強(qiáng)Web應(yīng)用程序的安全性。3.1.2系統(tǒng)開發(fā)環(huán)境以及運(yùn)行環(huán)境 開發(fā)環(huán)境：操作系