在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

鍍金池/ 教程/ GO/ 9.1 預(yù)防CSRF攻擊
7 文本處理
3 Web基礎(chǔ)
14 擴展Web框架
10.4 小結(jié)
2.2 Go基礎(chǔ)
2.8 總結(jié)
6.1 session和cookie
5.5 使用beedb庫進行ORM開發(fā)
8.3 REST
13.6 小結(jié)
5.4 使用PostgreSQL數(shù)據(jù)庫
14.6 pprof支持
14.1 靜態(tài)文件支持
11.2 使用GDB調(diào)試
7.7 小結(jié)
1 GO環(huán)境配置
14.5 多語言支持
7.1 XML處理
1.5 總結(jié)
13 如何設(shè)計一個Web框架
14.3 表單及驗證支持
12 部署與維護
10 國際化和本地化
1.1 Go 安裝
6.2 Go如何使用session
5.6 NOSQL數(shù)據(jù)庫操作
6.5 小結(jié)
9.4 避免SQL注入
12.1 應(yīng)用日志
4.2 驗證表單的輸入
10.1 設(shè)置默認地區(qū)
1.3 Go 命令
9.6 加密和解密數(shù)據(jù)
4.1 處理表單的輸入
4.4 防止多次遞交表單
11.3 Go怎么寫測試用例
8 Web服務(wù)
12.3 應(yīng)用部署
5.7 小結(jié)
12.5 小結(jié)
11 錯誤處理,調(diào)試和測試
9.2 確保輸入過濾
14.2 Session支持
6.4 預(yù)防session劫持
12.4 備份和恢復(fù)
8.1 Socket編程
13.1 項目規(guī)劃
13.4 日志和配置設(shè)計
7.6 字符串處理
13.2 自定義路由器設(shè)計
6.3 session存儲
3.4 Go的http包詳解
8.2 WebSocket
10.3 國際化站點
7.5 文件操作
7.4 模板處理
9.1 預(yù)防CSRF攻擊
13.3 controller設(shè)計
2.6 interface
14.4 用戶認證
2.3 流程和函數(shù)
附錄A 參考資料
11.1 錯誤處理
9.5 存儲密碼
9.3 避免XSS攻擊
12.2 網(wǎng)站錯誤處理
6 session和數(shù)據(jù)存儲
2.4 struct類型
3.3 Go如何使得Web工作
2.5 面向?qū)ο?/span>
3.1 Web工作方式
1.2 GOPATH與工作空間
2.1 你好,Go
9.7 小結(jié)
13.5 實現(xiàn)博客的增刪改
7.2 JSON處理
10.2 本地化資源
7.3 正則處理
2 Go語言基礎(chǔ)
5.1 database/sql接口
4.5 處理文件上傳
8.5 小結(jié)
4.3 預(yù)防跨站腳本
5.3 使用SQLite數(shù)據(jù)庫
14.7 小結(jié)
3.2 Go搭建一個Web服務(wù)器
2.7 并發(fā)
5 訪問數(shù)據(jù)庫
4 表單
3.5 小結(jié)
1.4 Go開發(fā)工具
11.4 小結(jié)
9 安全與加密
5.2 使用MySQL數(shù)據(jù)庫
4.6 小結(jié)
8.4 RPC

9.1 預(yù)防CSRF攻擊

什么是CSRF

CSRF(Cross-site request forgery),中文名稱:跨站請求偽造,也被稱為:one click attack/session riding,縮寫為:CSRF/XSRF。

那么CSRF到底能夠干嘛呢?你可以這樣簡單的理解:攻擊者可以盜用你的登陸信息,以你的身份模擬發(fā)送各種請求。攻擊者只要借助少許的社會工程學的詭計,例如通過QQ等聊天軟件發(fā)送的鏈接(有些還偽裝成短域名,用戶無法分辨),攻擊者就能迫使Web應(yīng)用的用戶去執(zhí)行攻擊者預(yù)設(shè)的操作。例如,當用戶登錄網(wǎng)絡(luò)銀行去查看其存款余額,在他沒有退出時,就點擊了一個QQ好友發(fā)來的鏈接,那么該用戶銀行帳戶中的資金就有可能被轉(zhuǎn)移到攻擊者指定的帳戶中。

所以遇到CSRF攻擊時,將對終端用戶的數(shù)據(jù)和操作指令構(gòu)成嚴重的威脅;當受攻擊的終端用戶具有管理員帳戶的時候,CSRF攻擊將危及整個Web應(yīng)用程序。

CSRF的原理

下圖簡單闡述了CSRF攻擊的思想

http://wiki.jikexueyuan.com/project/go-web-programming/images/9.1.csrf.png" alt="" />

圖9.1 CSRF的攻擊過程

從上圖可以看出,要完成一次CSRF攻擊,受害者必須依次完成兩個步驟 :

  • 1.登錄受信任網(wǎng)站A,并在本地生成Cookie 。
  • 2.在不退出A的情況下,訪問危險網(wǎng)站B。

看到這里,讀者也許會問:“如果我不滿足以上兩個條件中的任意一個,就不會受到CSRF的攻擊”。是的,確實如此,但你不能保證以下情況不會發(fā)生:

  • 你不能保證你登錄了一個網(wǎng)站后,不再打開一個tab頁面并訪問另外的網(wǎng)站,特別現(xiàn)在瀏覽器都是支持多tab的。
  • 你不能保證你關(guān)閉瀏覽器了后,你本地的Cookie立刻過期,你上次的會話已經(jīng)結(jié)束。
  • 上圖中所謂的攻擊網(wǎng)站,可能是一個存在其他漏洞的可信任的經(jīng)常被人訪問的網(wǎng)站。

因此對于用戶來說很難避免在登陸一個網(wǎng)站之后不點擊一些鏈接進行其他操作,所以隨時可能成為CSRF的受害者。

CSRF攻擊主要是因為Web的隱式身份驗證機制,Web的身份驗證機制雖然可以保證一個請求是來自于某個用戶的瀏覽器,但卻無法保證該請求是用戶批準發(fā)送的。

如何預(yù)防CSRF

過上面的介紹,讀者是否覺得這種攻擊很恐怖,意識到恐怖是個好事情,這樣會促使你接著往下看如何改進和防止類似的漏洞出現(xiàn)。

CSRF的防御可以從服務(wù)端和客戶端兩方面著手,防御效果是從服務(wù)端著手效果比較好,現(xiàn)在一般的CSRF防御也都在服務(wù)端進行。

服務(wù)端的預(yù)防CSRF攻擊的方式方法有多種,但思想上都是差不多的,主要從以下2個方面入手:

  • 1、正確使用GET,POST和Cookie;
  • 2、在非GET請求中增加偽隨機數(shù);

我們上一章介紹過REST方式的Web應(yīng)用,一般而言,普通的Web應(yīng)用都是以GET、POST為主,還有一種請求是Cookie方式。我們一般都是按照如下方式設(shè)計應(yīng)用:

1、GET常用在查看,列舉,展示等不需要改變資源屬性的時候;

2、POST常用在下達訂單,改變一個資源的屬性或者做其他一些事情;

接下來我就以Go語言來舉例說明,如何限制對資源的訪問方法:

mux.Get("/user/:uid", getuser)
mux.Post("/user/:uid", modifyuser)

這樣處理后,因為我們限定了修改只能使用POST,當GET方式請求時就拒絕響應(yīng),所以上面圖示中GET方式的CSRF攻擊就可以防止了,但這樣就能全部解決問題了嗎?當然不是,因為POST也是可以模擬的。

因此我們需要實施第二步,在非GET方式的請求中增加隨機數(shù),這個大概有三種方式來進行:

  • 為每個用戶生成一個唯一的cookie token,所有表單都包含同一個偽隨機值,這種方案最簡單,因為攻擊者不能獲得第三方的Cookie(理論上),所以表單中的數(shù)據(jù)也就構(gòu)造失敗,但是由于用戶的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取,所以這個方案必須要在沒有XSS的情況下才安全。
  • 每個請求使用驗證碼,這個方案是完美的,因為要多次輸入驗證碼,所以用戶友好性很差,所以不適合實際運用。
  • 不同的表單包含一個不同的偽隨機值,我們在4.4小節(jié)介紹“如何防止表單多次遞交”時介紹過此方案,復(fù)用相關(guān)代碼,實現(xiàn)如下:

生成隨機數(shù)token

h := md5.New()
io.WriteString(h, strconv.FormatInt(crutime, 10))
io.WriteString(h, "ganraomaxxxxxxxxx")
token := fmt.Sprintf("%x", h.Sum(nil))

t, _ := template.ParseFiles("login.gtpl")
t.Execute(w, token)

輸出token

<input type="hidden" name="token" value="{{.}}">

驗證token

r.ParseForm()
token := r.Form.Get("token")
if token != "" {
    //驗證token的合法性
} else {
    //不存在token報錯
}

這樣基本就實現(xiàn)了安全的POST,但是也許你會說如果破解了token的算法呢,按照理論上是,但是實際上破解是基本不可能的,因為有人曾計算過,暴力破解該串大概需要2的11次方時間。

總結(jié)

跨站請求偽造,即CSRF,是一種非常危險的Web安全威脅,它被Web安全界稱為“沉睡的巨人”,其威脅程度由此“美譽”便可見一斑。本小節(jié)不僅對跨站請求偽造本身進行了簡單介紹,還詳細說明造成這種漏洞的原因所在,然后以此提了一些防范該攻擊的建議,希望對讀者編寫安全的Web應(yīng)用能夠有所啟發(fā)。

上一篇:14 擴展Web框架下一篇:9.7 小結(jié)