系統(tǒng)安全培訓(xùn)Web安全性課件

1、系統(tǒng)安全Web安全性2010年9月2009中國計算機網(wǎng)絡(luò)安全應(yīng)急年會資料安全性問題之一SQL注入什么是 SQL Injection: (SQL注入)就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字符串，欺騙服務(wù)器執(zhí)行惡意的SQL命令。簡而言之，是在輸入的數(shù)據(jù)字符串中夾帶SQL指令，在設(shè)計不良的程序中忽略了檢查，那么在這些夾帶的指令就會被數(shù)據(jù)庫服務(wù)器誤認(rèn)為是正常的SQL指令而運行，因此招致到破壞安全性問題之一SQL注入SQL Injection: (SQL注入)SQL注入是最常見的攻擊方式，它的主要原理是：攻擊者通過改變WEB頁的參數(shù)，直接將SQL片斷提交到服務(wù)器，并在服務(wù)器端執(zhí)

2、行的過程。安全性問題之一SQL注入SQL注入的原因1、在應(yīng)用程序中使用字符串聯(lián)結(jié)方式組合SQL指令2、在應(yīng)用程序鏈接數(shù)據(jù)庫時使用權(quán)限過大的帳號（例如使用SA）3、在數(shù)據(jù)庫中開放了不必要但權(quán)力過大的功能（如，在SQLServer中的的xp_cmdshell延伸預(yù)存程序或是OLE Automation預(yù)存程序等）4、太過于信任用戶所輸入的數(shù)據(jù)，未限制輸入的字符數(shù)安全性問題之一SQL注入SQL注入的危害修改數(shù)據(jù)庫內(nèi)容刪除其它表竊取數(shù)據(jù)到本地執(zhí)行系統(tǒng)命令，進而修改或控制操作系統(tǒng)、破壞硬盤數(shù)據(jù)等特點攻擊耗時少、危害大安全性問題之一SQL注入問題代碼（ASP+MS SQL Server）if Reques

3、t.QueryString(id) is NoThing then id=1else id=Request.QueryString(id)end ifsql=select title,content from news where id=&idset rs=Server.CreateObject(adodb.Recordset)rs.Open sql,connection,1,1安全性問題之一SQL注入修改數(shù)據(jù)庫內(nèi)容提交語句http:/localhost/news.asp?id=1;update news set title=test where title=oldtitle執(zhí)行語句：sele

4、ct title,content from news where id=1;update news set title=test where title=oldtitle安全性問題之一SQL注入刪除其它表提交語句http:/localhost/news.asp?id=1;drop table tablename執(zhí)行語句：select title,content from news where id=1;drop table tablename服務(wù)器返回的錯誤信息關(guān)鍵文件路徑服務(wù)器返回的錯誤信息如何預(yù)防SQL注入? 從應(yīng)用程序的角度來講,我們要做以下三項工作:1. 轉(zhuǎn)義敏感字符及字符串(SQL的

5、敏感字符包括:“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”/”,”.”,”;”,”,”-”,”%”,”0 x”,”=!-*/()|”,和”空格”)。2. 屏蔽出錯信息：阻止攻擊者知道攻擊的結(jié)果3. 服務(wù)端正式處理之前對提交數(shù)據(jù)的合法性進行檢查(包括：數(shù)據(jù)類型,數(shù)據(jù)長度,敏感字符的校驗) 。在確認(rèn)客戶端的輸入合法之前,服務(wù)端拒絕進行關(guān)鍵性的處理操作。如何預(yù)防SQL注入?從實際應(yīng)用還需要注意：1. 只要是提交的數(shù)據(jù)包含非法字符，或者要替換為安全字符，或者提交的數(shù)據(jù)要替換為默認(rèn)值。2. 含有非法字符串的數(shù)據(jù)提交不應(yīng)該顯示“您所提交的數(shù)據(jù)非法”等類似

6、的提示。因為對于訪問者而言，這是沒有必要的。3. 盡可能完善操作日志記錄和錯誤日記記錄。 安全性問題之二上傳文件漏洞偽造客戶端繞過上傳后綴名檢查可能導(dǎo)致上傳木馬解決方法：使用白名單，后臺檢查防止木馬執(zhí)行的方法給各個不必要的目錄，去掉“執(zhí)行”權(quán)限;刪除不需要的程序映射。安全性問題之三XSSCross-Site Scripting (XSS):(跨站點腳本攻擊)XSS是由于Web程序沒有對用戶提交的HTML內(nèi)容進行適當(dāng)?shù)倪^濾，這樣攻擊者就可能在你的Web頁中插入一些HTML語句，這些語句通過以標(biāo)簽的形式出現(xiàn)。攻擊者通常使用跨站腳本攻擊來竊取COOKIES 和 SESSION信息，或是欺騙用戶將隱私

7、信息暴露給錯誤對象(又稱為釣魚) 。問題三XSS Results for window.open(? . document.cookie .) Attack Server受害人服務(wù)器 受害人客戶端 user gets bad linkuser clicks on linkvictim echoes user input/search.php ? term = . 安全性問題之三XSS跨站腳本XSS利用示例Cookie、Session會話CookieASPSESSIONIDXXXXXXXX、JSESSIONID、PHPSESSID安全性問題之三XSS在html編輯輸入：顯示cookie安全性問題

8、之四SCRFCross-Site Request Forgery (SCRF):(跨站點請求偽造) SCRF的特性就是利用網(wǎng)站對用戶標(biāo)識的信任，欺騙用戶的瀏覽器發(fā)送HTTP請求給目標(biāo)站點。安全性問題之四SCRF瀏覽器和網(wǎng)站建立認(rèn)證的會話Web瀏覽器跟可信的站點建立了一個經(jīng)認(rèn)證的會話之后，只要是通過該Web瀏覽器這個認(rèn)證的會話所發(fā)送的請求，都被視為可信的動作。安全性問題之四SCRF瀏覽器發(fā)送有效的請求瀏覽器正在發(fā)送一個有效的請求，即Web瀏覽器企圖執(zhí)行一個可信的動作?？尚诺恼军c經(jīng)確認(rèn)發(fā)現(xiàn)，該Web瀏覽器已通過認(rèn)證，所以該動作將被執(zhí)行。安全性問題之四SCRF惡意站點偽造的有效請求圖中，發(fā)生了一個S

9、CRF攻擊。發(fā)起攻擊的站點致使瀏覽器向可信的站點發(fā)送一個請求。該可信的站點認(rèn)為，來自該Web瀏覽器的請求都是經(jīng)過認(rèn)證的有效請求，所以執(zhí)行這個“可信的動作”。SCRF攻擊之所以會發(fā)生，其根本原因就是Web站點所驗證的是Web瀏覽器而非用戶本身。安全性問題之四SCRF假如張三在瀏覽目標(biāo)站點A，那么站點A便會給張三的瀏覽器一個cookie，用于存放一個偽隨機數(shù)作為會話標(biāo)識符sid，以跟蹤她的會話。該站點會要求張三進行登錄，當(dāng)她輸入有效的用戶名和口令時，該站點會記錄這樣一個事實：張三已經(jīng)登錄到會話sid。當(dāng)張三發(fā)送一個請求到站點A時，她的瀏覽器就會自動地發(fā)送包含sid的會話cookie。之后，站點A就

10、會使用站點的會話記錄來識別該會話是否來自張三。安全性問題之四SCRF現(xiàn)在，我們假設(shè)張三訪問了一個惡意站點B，該站點提供的內(nèi)容中的JavaScript代碼或者圖像標(biāo)簽會導(dǎo)致張三的瀏覽器向站點A發(fā)送一個HTTP請求。由于該請求是發(fā)給站點A的，所以張三的瀏覽器自動地給該請求附上與站點A對應(yīng)的該會話cookie的sid。站點A看到該請求時，它就能通過該cookie的推斷出：該請求來自張三，所以站點A就會對張三的帳戶執(zhí)行所請求的操作。這樣，SCRF攻擊就能得逞了。安全性問題之四SCRF客戶端 (認(rèn)證)服務(wù)器Cookie: sid第三方站點客戶端 (惡意命令請求)服務(wù)器第三方站點內(nèi)容：指令：張三的賬戶A向

11、賬號B轉(zhuǎn)賬，交易金額1000安全性問題之四SCRF總之，只要身份認(rèn)證是隱式進行的，就會存在SCRF攻擊的危險，因為瀏覽器發(fā)出請求這一動作未必是受用戶的指使。原則上，這種威脅可以通過對每個發(fā)送至該站點的請求都要求用戶進行顯式的、不可欺騙的動作(比如重新輸入用戶名和口令)來消除，但實際上這會導(dǎo)致嚴(yán)重的易用性問題。大部分標(biāo)準(zhǔn)和廣泛應(yīng)用的認(rèn)證機制都無法防止CSRF攻擊。安全性問題之四SCRFSCRF成功發(fā)動攻擊前提是，用戶必須已經(jīng)登錄到目標(biāo)站點，并且必須瀏覽了攻擊者的站點或被攻擊者部分控制的站點。安全性問題之四SCRFSCRF和XSS攻擊的區(qū)別在于，XSS攻擊需要JavaScript，而CSRF攻擊不

12、需要；XSS攻擊要求站點接受惡意代碼，而對于SCRF攻擊來說，惡意代碼位于第三方站點上。防御XSS攻擊的措施無法保護站點不受SCRF攻擊的危害。如果站點具有XSS攻擊漏洞，那么它也有SCRF攻擊漏洞。但是，即使站點針對XSS攻擊采取了全面保護，卻仍然面臨SCRF攻擊的威脅。安全性問題之五XSIOCross Site Image Overlaying (XSIO) :跨站圖像疊加XSIO是因為沒有限制圖片的position屬性為absolute，導(dǎo)致可以控制一張圖片出現(xiàn)在網(wǎng)頁的任意位置。那么我們就可以用這張圖片去覆蓋網(wǎng)頁上的任意一個位置（link、button）。這就可以導(dǎo)致頁面破壞。而給圖片設(shè)

13、置一個鏈接后，很顯然就可以起到一個釣魚的作用。由于對正常的HTML 標(biāo)簽是沒有做過濾的，所以我們可以用這些標(biāo)簽或CSS樣式來實施XSIO攻擊。安全性問題之六XSIOCross Site Image Overlaying (XSIO) :跨站圖像疊加測試方法:安全性問題之六XSIOhttp:/XX.XXX.X.XXX/XX_bbs/websource/BBS/article_det.aspx?id=15&aid=2015跨站圖像疊加 安全性問題的根源客戶端數(shù)據(jù)的不可信任性。Never under any circumstances trust data from the browser.（從不要

14、相信來自瀏覽器端的數(shù)據(jù)，因為你永遠不可能知道在瀏覽器進行數(shù)據(jù)操作是你的用戶還是正在尋找攻擊漏洞的黑客） 不信任客戶端如何交換數(shù)據(jù)？解決方法：安全性測試安全性測試是一個很大的題目，首先取決于要達到怎樣的安全程度。不要期望網(wǎng)站可以達到100%的安全。解決方法：安全性測試(1)如何進行XSS測試?首先,找到帶有參數(shù)傳遞的URL,如登錄頁面,搜索頁面,提交評論,發(fā)表留言頁面等等。其次,在頁面參數(shù)中輸入如下語句(如:Javascript,VB script, HTML,ActiveX, Flash)來進行測試：alert(document.cookie)解決方法：安全性測試 (2)如何預(yù)防XSS漏洞?從應(yīng)用程序的角度來講,要進行以下幾項預(yù)防:對Javascript,VBscript, HTML,ActiveX, Flash等語句或腳本進行轉(zhuǎn)義。在服務(wù)端正式處理之前對提交數(shù)據(jù)的合法性進行檢查(包括:數(shù)據(jù)類型,數(shù)據(jù)長度,敏感字符的校驗) 等。從測試人員的角度來講,要從需求檢查和