系統(tǒng)安全培訓(xùn)-Web安全性課件_第1頁
系統(tǒng)安全培訓(xùn)-Web安全性課件_第2頁
系統(tǒng)安全培訓(xùn)-Web安全性課件_第3頁
系統(tǒng)安全培訓(xùn)-Web安全性課件_第4頁
系統(tǒng)安全培訓(xùn)-Web安全性課件_第5頁
已閱讀5頁，還剩32頁未讀， 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明：本文檔由用戶提供并上傳，收益歸屬內(nèi)容提供方，若內(nèi)容存在侵權(quán)，請進行舉報或認領(lǐng)

文檔簡介

系統(tǒng)安全

——Web安全性2014年7月2014中國計算機網(wǎng)絡(luò)安全應(yīng)急年會資料安全性問題之一SQL注入什么是SQLInjection:(SQL注入)

就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字符串，欺騙服務(wù)器執(zhí)行惡意的SQL命令。

簡而言之，是在輸入的數(shù)據(jù)字符串中夾帶SQL指令，在設(shè)計不良的程序中忽略了檢查，那么在這些夾帶的指令就會被數(shù)據(jù)庫服務(wù)器誤認為是正常的SQL指令而運行，因此招致到破壞安全性問題之一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ù)存程序或是OLEAutomation預(yù)存程序等）4、太過于信任用戶所輸入的數(shù)據(jù)，未限制輸入的字符數(shù)安全性問題之一SQL注入SQL注入的危害修改數(shù)據(jù)庫內(nèi)容刪除其它表竊取數(shù)據(jù)到本地執(zhí)行系統(tǒng)命令，進而修改或控制操作系統(tǒng)、破壞硬盤數(shù)據(jù)等特點攻擊耗時少、危害大安全性問題之一SQL注入問題代碼（ASP+MSSQLServer）ifRequest.QueryString("id")isNoThingthenid=1else

id=Request.QueryString("id")endifsql="selecttitle,contentfrom[news]whereid="&idsetrs=Server.CreateObject("adodb.Recordset")rs.Opensql,connection,1,1安全性問題之一SQL注入修改數(shù)據(jù)庫內(nèi)容提交語句http://localhost/news.asp?id=1;updatenewssettitle='test'wheretitle='oldtitle’執(zhí)行語句：selecttitle,contentfrom[news]whereid=1;updatenewssettitle='test'wheretitle='oldtitle'服務(wù)器返回的錯誤信息關(guān)鍵文件路徑如何預(yù)防SQL注入?

從應(yīng)用程序的角度來講,我們要做以下三項工作:1.轉(zhuǎn)義敏感字符及字符串(SQL的敏感字符包括:“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”,和”空格”)。2.屏蔽出錯信息：阻止攻擊者知道攻擊的結(jié)果3.服務(wù)端正式處理之前對提交數(shù)據(jù)的合法性進行檢查(包括：數(shù)據(jù)類型,數(shù)據(jù)長度,敏感字符的校驗)。在確認客戶端的輸入合法之前,服務(wù)端拒絕進行關(guān)鍵性的處理操作。安全性問題之二上傳文件漏洞偽造客戶端繞過上傳后綴名檢查可能導(dǎo)致上傳木馬解決方法：使用白名單，后臺檢查防止木馬執(zhí)行的方法給各個不必要的目錄，去掉“執(zhí)行”權(quán)限;刪除不需要的程序映射。安全性問題之三XSSCross-SiteScripting(XSS):(跨站點腳本攻擊)XSS是由于Web程序沒有對用戶提交的HTML內(nèi)容進行適當(dāng)?shù)倪^濾，這樣攻擊者就可能在你的Web頁中插入一些HTML語句，這些語句通過以<script>標(biāo)簽的形式出現(xiàn)。攻擊者通常使用跨站腳本攻擊來竊取COOKIES

和SESSION信息，或是欺騙用戶將隱私信息暴露給錯誤對象(又稱為釣魚)。問題三XSS<html>Resultsfor<script>window.open(?...document.cookie...)</script></html>AttackServer受害人服務(wù)器受害人客戶端usergetsbadlinkuserclicksonlinkvictimechoesuserinput/search.php?term=<script>...</script>安全性問題之三XSS跨站腳本XSS利用示例Cookie、Session會話CookieASPSESSIONIDXXXXXXXX、JSESSIONID、PHPSESSID安全性問題之四SCRFCross-SiteRequestForgery(SCRF):(跨站點請求偽造)SCRF的特性就是利用網(wǎng)站對用戶標(biāo)識的信任，欺騙用戶的瀏覽器發(fā)送HTTP請求給目標(biāo)站點。安全性問題之四SCRF瀏覽器和網(wǎng)站建立認證的會話Web瀏覽器跟可信的站點建立了一個經(jīng)認證的會話之后，只要是通過該Web瀏覽器這個認證的會話所發(fā)送的請求，都被視為可信的動作。安全性問題之四SCRF惡意站點偽造的有效請求圖中，發(fā)生了一個SCRF攻擊。發(fā)起攻擊的站點致使瀏覽器向可信的站點發(fā)送一個請求。該可信的站點認為，來自該Web瀏覽器的請求都是經(jīng)過認證的有效請求，所以執(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就會使用站點的會話記錄來識別該會話是否來自張三。安全性問題之四SCRF客戶端————(認證)——服務(wù)器Cookie:sid第三方站點——客戶端——(惡意命令請求)———服務(wù)器第三方站點內(nèi)容：<imgsrc=“/Transfer.html?srcAmount=A&TargetAmount=B&Turnover=1000”>指令：張三的賬戶A向賬號B轉(zhuǎn)賬，交易金額1000安全性問題之四SCRF總之，只要身份認證是隱式進行的，就會存在SCRF攻擊的危險，因為瀏覽器發(fā)出請求這一動作未必是受用戶的指使。原則上，這種威脅可以通過對每個發(fā)送至該站點的請求都要求用戶進行顯式的、不可欺騙的動作(比如重新輸入用戶名和口令)來消除，但實際上這會導(dǎo)致嚴(yán)重的易用性問題。大部分標(biāo)準(zhǔn)和廣泛應(yīng)用的認證機制都無法防止CSRF攻擊。安全性問題之四SCRFSCRF成功發(fā)動攻擊前提是，用戶必須已經(jīng)登錄到目標(biāo)站點，并且必須瀏覽了攻擊者的站點或被攻擊者部分控制的站點。安全性問題之五XSIOCrossSiteImageOverlaying(XSIO):跨站圖像疊加XSIO是因為沒有限制圖片的position屬性為absolute，導(dǎo)致可以控制一張圖片出現(xiàn)在網(wǎng)頁的任意位置。那么我們就可以用這張圖片去覆蓋網(wǎng)頁上的任意一個位置（link、button）。這就可以導(dǎo)致頁面破壞。而給圖片設(shè)置一個鏈接后，很顯然就可以起到一個釣魚的作用。由于對正常的HTML標(biāo)簽是沒有做過濾的，所以我們可以用這些標(biāo)簽或CSS樣式來實施XSIO攻擊。安全性問題之六XSIOCrossSiteImageOverlaying(XSIO):跨站圖像疊加測試方法:<ahref=http://><imgsrc=""style="position:absolute;left:123px;top:123px;"></a>安全性問題之六XSIOhttp://XX.XXX.X.XXX/XX_bbs/websource/BBS/article_det.aspx?id=15&aid=2015<ahref="javAScrIpT:alert('跨站圖像疊加XSIO');"><imgheight="240"src="/BL_BBS/uploads/a2.JPG"width="320"style="filter:alpha(opacity=30);left:0px;position:absolute;top:100px;opacity:0.3"/></a>跨站圖像疊加安全性問題的根源客戶端數(shù)據(jù)的不可信任性。Never—underanycircumstances—trustdatafromthebrowser.（從不要相信來自瀏覽器端的數(shù)據(jù)，因為你永遠不可能知道在瀏覽器進行數(shù)據(jù)操作是你的用戶還是正在尋找攻擊漏洞的黑客）不信任客戶端如何交換數(shù)據(jù)？解決方法：安全性測試安全性測試是一個很大的題目，首先取決于要達到怎樣的安全程度。不要期望網(wǎng)站可以達到100%的安全。解決方法：安全性測試(1)如何進行XSS測試?首先,找到帶有參數(shù)傳遞的URL,如登錄頁面,搜索頁面,提交評論,發(fā)表留言頁面等等。其次,在頁面參數(shù)中輸入如下語句(如:Javascript,VBscript,HTML,ActiveX,Flash)來進行測試：<script>alert(document.cookie)</script>解決方法：安全性測試(2)如何預(yù)防XSS漏洞?從應(yīng)用程序的角度來講,要進行以下幾項預(yù)防:對Javascript,VBscript,HTML,ActiveX,Flash等語句或腳本進行轉(zhuǎn)義。在服務(wù)端正式處理之前對提交數(shù)據(jù)的合法性進行檢查(包括:數(shù)據(jù)類型,數(shù)據(jù)長度,敏感字符的校驗)等。從測試人員的角度來講,要從需求檢查和執(zhí)行測試過程兩個階段來完成XSS檢查:在

溫馨提示

  • 1. 本站所有資源如無特殊說明，都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等，如果需要附件，請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙，網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽，若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間，僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理，對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯，并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容，請與我們聯(lián)系，我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論