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

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