XSS 攻擊
XSS (Cross-Site Scripting瞎惫,跨站腳本攻擊)是一種常見的web安全漏洞,它允許攻擊者將惡意代碼植入到提供給其它用戶使用的頁面中蔗怠。不同于大多數(shù)攻擊(一般只涉及攻擊者和受害者),XSS涉及到三方,即攻擊者叙凡、客戶端與Web應用。XSS的攻擊目標是為了盜取存儲在客戶端的cookie或者其他網(wǎng)站用于識別客戶端身份的敏感信息密末。一旦獲取到合法用戶的信息后握爷,攻擊者甚至可以假冒合法用戶與網(wǎng)站進行交互。
-
手段和目的
- 盜用cookie严里,獲取敏感信息新啼。
- 利用植入Flash,通過crossdomain權限設置進一步獲取更高權限刹碾;或者利用Java等得到類似的操作
- 利用iframe燥撞、frame、XMLHttpRequest或上述Flash等方式迷帜,以(被攻擊者)用戶的身份執(zhí)行一些管理動作
- 利用可被攻擊的域受到其他域信任的特點物舒,以受信任來源的身份請求一些平時不允許的操作,如進行不當?shù)耐镀被顒?/li>
- 在訪問量極大的一些頁面上的XSS可以攻擊一些小型網(wǎng)站瞬矩,實現(xiàn)DDoS攻擊的效果
產(chǎn)生原因
Web應用未對用戶提交請求的數(shù)據(jù)做充分的檢查過濾茶鉴,允許用戶在提交的數(shù)據(jù)中摻入HTML代碼(最主要的是“>”锋玲、“<”)景用,并將未經(jīng)轉義的惡意代碼輸出到第三方用戶的瀏覽器解釋執(zhí)行,是導致XSS漏洞的產(chǎn)生原因預防
堅決不要相信用戶的任何輸入惭蹂,并過濾掉輸入中的所有特殊字符伞插。這樣就能消滅絕大部分的XSS攻擊。
-
目前防御XSS主要有如下幾種方式:
過濾特殊字符
避免XSS的方法之一主要是將用戶所提供的內(nèi)容進行過濾盾碗,Go語言提供了HTML的過濾函數(shù):
text/template包下面的HTMLEscapeString媚污、JSEscapeString等函數(shù)
CSRF
CSRF(Cross-site request forgery),中文名稱:跨站請求偽造
原理
跨站請求攻擊廷雅,簡單地說耗美,是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經(jīng)認證過的網(wǎng)站并執(zhí)行一些操作(如發(fā)郵件,發(fā)消息航缀,甚至財產(chǎn)操作如轉賬和購買商品)商架。由于瀏覽器曾經(jīng)認證過,所以被訪問的網(wǎng)站會認為是真正的用戶操作而去執(zhí)行芥玉。這利用了web中用戶身份驗證的一個漏洞:簡單的身份驗證只能保證請求發(fā)自某個用戶的瀏覽器蛇摸,卻不能保證請求本身是用戶自愿發(fā)出的。
例子
假如一家銀行用以執(zhí)行轉賬操作的URL地址如下: http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
那么灿巧,一個惡意攻擊者可以在另一個網(wǎng)站上放置如下代碼: <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
如果有賬戶名為Alice的用戶訪問了惡意站點赶袄,而她之前剛訪問過銀行不久揽涮,登錄信息尚未過期,那么她就會損失1000資金饿肺。
這種惡意的網(wǎng)址可以有很多種形式蒋困,藏身于網(wǎng)頁中的許多地方。此外敬辣,攻擊者也不需要控制放置惡意網(wǎng)址的網(wǎng)站家破。例如他可以將這種地址藏在論壇,博客等任何用戶生成內(nèi)容的網(wǎng)站中购岗。這意味著如果服務器端沒有合適的防御措施的話汰聋,用戶即使訪問熟悉的可信網(wǎng)站也有受攻擊的危險。
透過例子能夠看出喊积,攻擊者并不能通過CSRF攻擊來直接獲取用戶的賬戶控制權烹困,也不能直接竊取用戶的任何信息。他們能做到的乾吻,是欺騙用戶瀏覽器髓梅,讓其以用戶的名義執(zhí)行操作
防御措施
-
檢查Referer字段
HTTP頭中有一個Referer字段,這個字段用以標明請求來源于哪個地址绎签。在處理敏感數(shù)據(jù)請求時枯饿,通常來說,Referer字段應和請求的地址位于同一域名下诡必。以上文銀行操作為例奢方,Referer字段地址通常應該是轉賬按鈕所在的網(wǎng)頁地址,應該也位于www.examplebank.com之下爸舒。而如果是CSRF攻擊傳來的請求蟋字,Referer字段會是包含惡意網(wǎng)址的地址,不會位于www.examplebank.com之下扭勉,這時候服務器就能識別出惡意的訪問鹊奖。
這種辦法簡單易行,工作量低涂炎,僅需要在關鍵訪問處增加一步校驗忠聚。但這種辦法也有其局限性,因其完全依賴瀏覽器發(fā)送正確的Referer字段唱捣。雖然http協(xié)議對此字段的內(nèi)容有明確的規(guī)定两蟀,但并無法保證來訪的瀏覽器的具體實現(xiàn),亦無法保證瀏覽器沒有安全漏洞影響到此字段爷光。并且也存在攻擊者攻擊某些瀏覽器垫竞,篡改其Referer字段的可能。
添加校驗token
由于CSRF的本質(zhì)在于攻擊者欺騙用戶去訪問自己設置的地址,所以如果要求在訪問敏感數(shù)據(jù)請求時欢瞪,要求用戶瀏覽器提供不保存在cookie中活烙,并且攻擊者無法偽造的數(shù)據(jù)作為校驗,那么攻擊者就無法再執(zhí)行CSRF攻擊遣鼓。這種數(shù)據(jù)通常是表單中的一個數(shù)據(jù)項啸盏。服務器將其生成并附加在表單中,其內(nèi)容是一個偽亂數(shù)骑祟。當客戶端通過表單提交請求時回懦,這個偽亂數(shù)也一并提交上去以供校驗。正常的訪問時次企,客戶端瀏覽器能夠正確得到并傳回這個偽亂數(shù)怯晕,而通過CSRF傳來的欺騙性攻擊中,攻擊者無從事先得知這個偽亂數(shù)的值缸棵,服務器端就會因為校驗token的值為空或者錯誤舟茶,拒絕這個可疑請求。
參考:維基百科