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

1、系統(tǒng)安全培訓(xùn)-Web安全性系統(tǒng)安全Web2014年7月系統(tǒng)安全培訓(xùn)-Web安全性2014中國計算機網(wǎng)絡(luò)安全應(yīng)急年會資料系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之一SQL注入n什么是 SQL Injection: (SQL注入)就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字符串，欺騙服務(wù)器執(zhí)行惡意的SQL命令。簡而言之，是在輸入的數(shù)據(jù)字符串中夾帶SQL指令，在設(shè)計不良的程序中忽略了檢查，那么在這些夾帶的指令就會被數(shù)據(jù)庫服務(wù)器誤認(rèn)為是正常的SQL指令而運行，因此招致到破壞系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之一SQL注入nSQL Injection: (SQL注入)SQL注入是最常見

2、的攻擊方式，它的主要原理是：攻擊者通過改變WEB頁的參數(shù)，直接將SQL片斷提交到服務(wù)器，并在服務(wù)器端執(zhí)行的過程。系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之一SQL注入nSQL注入的原因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ù)系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之一SQL注入nSQL注入的危害修改數(shù)據(jù)庫內(nèi)容刪除其它表竊取數(shù)據(jù)到本地執(zhí)行

3、系統(tǒng)命令，進(jìn)而修改或控制操作系統(tǒng)、破壞硬盤數(shù)據(jù)等n特點攻擊耗時少、危害大系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之一SQL注入n問題代碼（ASP+MS SQL Server）if Request.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系統(tǒng)安全培訓(xùn)-Web安全性安全

4、性問題之一SQL注入n修改數(shù)據(jù)庫內(nèi)容提交語句1;update news set title=test where title=oldtitle執(zhí)行語句：select title,content from news where id=1;update news set title=test where title=oldtitle系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之一SQL注入n刪除其它表提交語句1;drop table tablename執(zhí)行語句：select title,content from news where id=1;drop table tablename系統(tǒng)安全培訓(xùn)-Web安

5、全性服務(wù)器返回的錯誤信息關(guān)鍵文件路徑系統(tǒng)安全培訓(xùn)-Web安全性服務(wù)器返回的錯誤信息系統(tǒng)安全培訓(xùn)-Web安全性如何預(yù)防SQL注入?n 從應(yīng)用程序的角度來講,我們要做以下三項工作:n1. 轉(zhuǎn)義敏感字符及字符串(SQL的敏感字符包括:n“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”/”,”.”,”;”,”,”-”,”%”,”0 x”,”=!-*/()|”,和”空格”)。n2. 屏蔽出錯信息：阻止攻擊者知道攻擊的結(jié)果n3. 服務(wù)端正式處理之前對提交數(shù)據(jù)的合法性進(jìn)行檢查(包括：數(shù)據(jù)類型,數(shù)據(jù)長度,敏感字符的校驗) 。在確認(rèn)客戶端的輸入合法之前,服務(wù)端拒絕

6、進(jìn)行關(guān)鍵性的處理操作。系統(tǒng)安全培訓(xùn)-Web安全性如何預(yù)防SQL注入?n從實際應(yīng)用還需要注意：n1. 只要是提交的數(shù)據(jù)包含非法字符，或者要替換為安全字符，或者提交的數(shù)據(jù)要替換為默認(rèn)值。n2. 含有非法字符串的數(shù)據(jù)提交不應(yīng)該顯示“您所提交的數(shù)據(jù)非法”等類似的提示。因為對于訪問者而言，這是沒有必要的。n3. 盡可能完善操作日志記錄和錯誤日記記錄。 系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之二上傳文件漏洞n偽造客戶端繞過上傳后綴名檢查n可能導(dǎo)致上傳木馬n解決方法：使用白名單，后臺檢查系統(tǒng)安全培訓(xùn)-Web安全性防止木馬執(zhí)行的方法n給各個不必要的目錄，去掉“執(zhí)行”權(quán)限;刪除不需要的程序映射。系統(tǒng)安全培訓(xùn)-We

7、b安全性安全性問題之三XSSnCross-Site Scripting (XSS):(跨站點腳本攻擊)XSS是由于Web程序沒有對用戶提交的HTML內(nèi)容進(jìn)行適當(dāng)?shù)倪^濾，這樣攻擊者就可能在你的Web頁中插入一些HTML語句，這些語句通過以標(biāo)簽的形式出現(xiàn)。攻擊者通常使用跨站腳本攻擊來竊取COOKIES 和 SESSION信息，或是欺騙用戶將隱私信息暴露給錯誤對象(又稱為釣魚) 。系統(tǒng)安全培訓(xùn)-Web安全性問題三XSS Results for window.open(? . document.cookie .) Attack Server受害人服務(wù)器 受害人客戶端 user gets bad lin

8、kuser clicks on linkvictim echoes user input ? term = . 系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之三XSSn跨站腳本XSS利用示例Cookie、Sessionn會話CookieASPSESSIONIDXXXXXXXX、JSESSIONID、PHPSESSID系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之三XSSn在html編輯輸入：顯示cookie系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之四SCRFnCross-Site Request Forgery (SCRF):(跨站點請求偽造) SCRF的特性就是利用網(wǎng)站對用戶標(biāo)識的信任，欺騙用戶的瀏覽器發(fā)送HT

9、TP請求給目標(biāo)站點。系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之四SCRFn瀏覽器和網(wǎng)站建立認(rèn)證的會話Web瀏覽器跟可信的站點建立了一個經(jīng)認(rèn)證的會話之后，只要是通過該Web瀏覽器這個認(rèn)證的會話所發(fā)送的請求，都被視為可信的動作。系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之四SCRFn瀏覽器發(fā)送有效的請求瀏覽器正在發(fā)送一個有效的請求，即Web瀏覽器企圖執(zhí)行一個可信的動作?？尚诺恼军c經(jīng)確認(rèn)發(fā)現(xiàn)，該Web瀏覽器已通過認(rèn)證，所以該動作將被執(zhí)行。系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之四SCRFn惡意站點偽造的有效請求圖中，發(fā)生了一個SCRF攻擊。發(fā)起攻擊的站點致使瀏覽器向可信的站點發(fā)送一個請求。該可信的站點認(rèn)為，來自

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

11、訓(xùn)-Web安全性安全性問題之四SCRFn現(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攻擊就能得逞了。系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之四SCRFn客戶端 (認(rèn)證)服務(wù)器nCookie: sidn第三方站點客戶端 (惡意命令請求)服務(wù)器n第三方站點內(nèi)容：n指令：張三的

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

13、四SCRFnSCRF和XSS攻擊的區(qū)別在于，XSS攻擊需要JavaScript，而CSRF攻擊不需要；XSS攻擊要求站點接受惡意代碼，而對于SCRF攻擊來說，惡意代碼位于第三方站點上。n防御XSS攻擊的措施無法保護(hù)站點不受SCRF攻擊的危害。如果站點具有XSS攻擊漏洞，那么它也有SCRF攻擊漏洞。但是，即使站點針對XSS攻擊采取了全面保護(hù)，卻仍然面臨SCRF攻擊的威脅。系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之五XSIOnCross Site Image Overlaying (XSIO) :跨站圖像疊加XSIO是因為沒有限制圖片的position屬性為absolute，導(dǎo)致可以控制一張圖片出現(xiàn)在

14、網(wǎng)頁的任意位置。那么我們就可以用這張圖片去覆蓋網(wǎng)頁上的任意一個位置（link、button）。這就可以導(dǎo)致頁面破壞。而給圖片設(shè)置一個鏈接后，很顯然就可以起到一個釣魚的作用。由于對正常的HTML 標(biāo)簽是沒有做過濾的，所以我們可以用這些標(biāo)簽或CSS樣式來實施XSIO攻擊。系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之六XSIOnCross Site Image Overlaying (XSIO) :跨站圖像疊加n測試方法:系統(tǒng)安全培訓(xùn)-Web安全性安全性問題之六XSIO跨站圖像疊加 系統(tǒng)安全培訓(xùn)-Web安全性安全性問題的根源n客戶端數(shù)據(jù)的不可信任性。nNever under any circumstanc

15、es trust data from the browser.（從不要相信來自瀏覽器端的數(shù)據(jù)，因為你永遠(yuǎn)不可能知道在瀏覽器進(jìn)行數(shù)據(jù)操作是你的用戶還是正在尋找攻擊漏洞的黑客） n不信任客戶端如何交換數(shù)據(jù)？系統(tǒng)安全培訓(xùn)-Web安全性解決方法：安全性測試n安全性測試是一個很大的題目，首先取決于要達(dá)到怎樣的安全程度。不要期望網(wǎng)站可以達(dá)到100%的安全。系統(tǒng)安全培訓(xùn)-Web安全性解決方法：安全性測試n(1)如何進(jìn)行XSS測試?首先,找到帶有參數(shù)傳遞的URL,如登錄頁面,搜索頁面,提交評論,發(fā)表留言頁面等等。其次,在頁面參數(shù)中輸入如下語句(如:Javascript,VB script, HTML,ActiveX, Flash)來進(jìn)行測試：alert(document.cookie)系統(tǒng)安全培訓(xùn)-Web安全性解決方法：安全性測試n (2)如何預(yù)防XSS