web 前端安全

前端主要面臨倆種類型的威脅

1.XSS（Cross Site Scripting）

　攻擊方式：惡意攻擊者往Web頁面裏插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的html代碼會被執行，從而達到惡意攻擊用戶的特殊目的。

2.CSRF（Cross-site request forgery跨站請求僞造，也被稱爲「one click attack」或者session riding，一般縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，而且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊每每不大流行（所以對其進行防範的資源也至關稀少）和難以防範，因此被認爲比XSS更具危險性。

 

攻擊例子：

假若有一個網站擁有轉帳功能（某個第三方支付提供的接口），我在該網站註冊一個用戶，而後給其餘用戶發送私信，私信內容包括「<img href='test?do=tranfer_money&to=someone&amout=100000" />」 。若是該網站直接輸出該內容，用戶打開此私信，圖片加載的同時就意味着以當前用戶狀態發送了轉帳請求。如果轉帳接口直接信任該用戶的請求,就會直接把錢轉給別人了。

 

這裏有倆個問題：

1.沒有對圖片地址進行適當的過濾（XSS）

2.被請求的服務器沒有進行嚴格的認證(CRFS)

 

問題解決

解決CSRF攻擊的思路分以下兩個步驟

1. 增長攻擊的難度。GET請求是很容易建立的，用戶點擊一個連接就能夠發起GET類型的請求，而POST請求相對比較難，攻擊者每每須要藉助JavaScript才能實現；所以，確保form表單或者服務端接口只接受POST類型的提交請求，能夠增長系統的安全性。
2. 對請求進行認證，確保該請求確實是用戶本人填寫表單或者發起請求並提交的，而不是第三者僞造的。

一個正經常使用戶修改網站信息的過程以下

• 用戶請求修改信息(1) -> 網站顯示用戶修改信息的表單(2) -> 用戶修改信息並提交(3) -> 網站接受用戶修改的數據並保存(4)

而一個CSRF攻擊則不會走這條路線，而是直接僞造第2步用戶提交信息

• 直接跳到第2步(1) -> 僞造要修改的信息並提交(2) -> 網站接受攻擊者修改參數數據並保存(3)

只要可以區分這兩種狀況，就可以預防CSRF攻擊。那麼如何區分呢？ 就是對第2步所提交的信息進行驗證，確保數據源自第一步的表單。具體的驗證過程以下：

• 用戶請求修改信息(1) -> 網站顯示用於修改信息的空白表單，表單中包含特殊的token同時把token保存在session中(2) -> 用戶修改信息並提交，同時發回token信息到服務端(3) -> 網站比對用戶發回的token和session中的token，應該一致，則接受用戶修改的數據，並保存

這樣，若是攻擊者僞造要修改的信息並提交，是沒辦法直接訪問到session的，因此也沒辦法拿到實際的token值；請求發送到服務端，服務端進行token校驗的時候，發現不一致，則直接拒絕這次請求。

 

參考

淘寶UED： 先後端分離模式下的安全解決方案