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的值為空或者錯誤舟茶，拒絕這個可疑請求。
參考：維基百科
