什麼是CSRF?
攻擊者盜用合法用戶的身份,以你的名義向第三方網站發送惡意請求。 CRSF能作的事情包括利用你的身份發郵件、發短信、進行交易轉帳等,甚至盜取你的帳號。
數據庫
所以,站點A會報據用戶C的權限來處理惡意站點B所發起的請求,而這個請求可能以用戶C的身份發送 郵件、短信、消息,以及進行轉帳支付等操做,這樣惡意站點B就達到了僞造用戶C請求站點 A的目的。
受害者只須要作下面兩件事情,攻擊者就可以完成CSRF攻擊:瀏覽器
不少狀況下所謂的惡意站點,頗有多是一個存在其餘漏洞(如XSS)的受信任且被不少人訪問的站點,這樣,普通用戶可能在不知不覺中便成爲了受害者安全
CSRF防護服務器
目前防護CSRF攻擊有三種策略:cookie
一、儘可能使用POST,限制GET
GET接口太容易被拿來作CSRF攻擊,只要構造一個img標籤,而img標籤又是不能過濾的數據。接口最好限制爲POST使用,GET則無效,下降攻擊風險。
固然POST並非萬無一失,攻擊者只要構造一個form就能夠,但須要在第三方頁面作,這樣就增長暴露的可能性。
二、將cookie設置爲HttpOnly
CRSF攻擊很大程度上是利用了瀏覽器的cookie,爲了防止站內的XSS漏洞盜取cookie,須要在cookie中設置「HttpOnly」屬性,這樣經過程序(如JavaScript腳本、Applet等)就沒法讀取到cookie信息,避免了攻擊者僞造cookie的狀況出現。
在Java的Servlet的API中設置cookie爲HttpOnly的代碼以下: response.setHeader( "Set-Cookie", "cookiename=cookievalue;HttpOnly");
三、增長token
CSRF攻擊之因此可以成功,是由於攻擊者能夠僞造用戶的請求,該請求中全部的用戶驗證信息都存在於cookie中,所以攻擊者能夠在不知道用戶驗證信息的狀況下直接利用用戶的cookie來經過安全驗證。由此可知,抵禦CSRF攻擊的關鍵在於:在請求中放入攻擊者所不能僞造的信息,而且該信總不存在於cookie之中。鑑於此,系統開發人員能夠在HTTP請求中以參數的形式加入一個隨機產生的token,並在服務端進行token校驗,若是請求中沒有token或者token內容不正確,則認爲是CSRF攻擊而拒絕該請求。
假設請求經過POST方式提交,則能夠在相應的表單中增長一個隱藏域: <input type="hidden" name="_toicen" value="tokenvalue"/>
token的值經過服務端生成,表單提交後token的值經過POST請求與參數一同帶到服務端,每次會話可使用相同的token,會話過時,則token失效,攻擊者因沒法獲取到token,也就沒法僞造請求。
四、經過Referer識別
根據HTTP協議,在HTTP頭中有一個字段叫Referer,它記錄了該HTTP請求的來源地址。在一般狀況下,訪問一個安全受限的頁面的請求都來自於同一個網站。但這種方法不是萬無一失的,referer的值是由瀏覽器提供的,咱們並不能保證瀏覽器沒有安全漏洞,目前已有一些方法能夠篡改referer值,並且有些用戶爲了保護本身的隱私能夠設置瀏覽器在發送請求時再也不提供referer值。cors
什麼是XSS?簡單來講,就是在頁面中植入惡意代碼。xss
xss一般能夠分爲兩大類:網站
(1)反射型xss。出如今URL中做爲參數提交到服務器,服務器解析並響應,響應結果中包含xss代碼,最後瀏覽器解析執行。spa
(2)存儲型xss。攻擊者輸入惡意的腳本數據存入數據庫,當其餘用戶讀取時,用戶瀏覽器將解析執行這段腳本。code
防護XSS攻擊
堅定不要相信用戶的任何輸入,並過濾掉輸入中的全部特殊字符。這樣就能消滅絕大部分的XSS攻擊。
解決辦法
若是爲Cookie中用於用戶認證的關鍵值設置httponly屬性,瀏覽器將會禁止js經過同源策略訪問cookie中設有httponly屬性的信息,所以以劫持用戶認證cookie爲目的XSS攻擊將會失敗。
但很明顯,只爲cookie中的值設置Httponly是不夠的,由於XSS攻擊並非只能獲取用戶COOKIE,它還能夠竊取用戶瀏覽器信息,模擬用戶身份執行操做等等。
CSRF攻擊是攻擊者利用用戶的身份操做用戶賬戶的一種攻擊方式,一般使用Anti CSRF Token來防護CSRF攻擊,同時要注意Token的保密性和隨機性。 而且CSRF攻擊問題通常是由服務端解決