前端安全-常見的攻擊以及防護

1、基礎知識

一、XSS（Cross Site Scripting）跨站腳本攻擊

（1）原理：頁面渲染的數據中包含可運行的腳本

（2）攻擊的基本類型：反射型（url參數直接注入）和存儲型（存儲到DB後讀取時注入）

（3）注入點：HTML節點內的內容（text）；HTML中DOM元素的屬性；Javascript代碼；富文本

//HTML節點內容注入
<div><script>alert(1);</script></div>  

//DOM屬性注入
<img src='/images/1.png' onerror='alert(1);'>  

//javascript代碼
<script>
    var a = '1';alert(1);''
</script>

//富文本是html標籤，文字，以及樣式的集合，很容易實現HTML節點內容注入和DOM屬性注入，有被攻擊的風險

 

二、CSRF（Cross Site Request Forgy）跨站請求僞造

原理：在第三方網站向本網站發起請求（如圖）

（1）用戶在a站前端頁面發起登陸（身份認證）請求

（2）a站後端確認身份，登陸成功，cookie中存在用戶的身份認證信息

（3）b站前端頁面向a站後端發起請求，帶着a站的cookie信息（身份認證信息），請求成功

綜上，能夠清楚的知道，只要用戶訪問了b站的前端頁面，b站就能夠在用戶徹底不知道的狀況下，帶着a站的用戶登陸態（cookie）向a站發起請求

三、點擊劫持

原理：第三方網站經過iframe內嵌某一個網站，而且將iframe設置爲透明不可見，將其覆蓋在其餘通過假裝的DOM上，假裝的可點擊DOM（按鈕等）與實際內嵌網站的可點擊DOM位置相同，當用戶點擊假裝的DOM時，實際上點擊的是iframe中內嵌的網頁的DOM從而觸發請求操做

特色：用戶本身作了點擊操做；用戶絕不知情；

 

2、如何防護

一、XSS攻擊防護

（1）瀏覽器自帶防護機制，主要應對反射型攻擊（HTML內容或屬性）：http響應頭中自動添加x-xss-protection，值爲0（關閉），1（打開），默認打開

（2）對特定字符作轉義：內容注入替換尖括號（ < => &lt;   > => &gt; ） 屬性注入替換單引號或雙引號（ " => &quot;  ' => &#39; ）

（3）CSP（Content Security Policy）內容安全策略：用於指定哪些內容可執行

//咱們能夠在http響應頭中設置Content-Security-Policy
//圖片能夠從任何地方加載(注意 "*" 通配符)
//多媒體文件僅容許從 media1.com 和 media2.com 加載(不容許從這些站點的子域名)
//可運行腳本僅容許來自於userscripts.example.com
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

//同時meta中也支持設置Content-Security-Policy
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

二、CSRF攻擊防護：

CSRF的發生有幾個特色，b站發送的請求帶着a站的cookie信息； b站發送請求不通過a站的前端；http請求頭中的referer爲b站。咱們能夠從這些特色入手，思考防護的辦法

（1）禁止第三方網站攜帶本網站的cookie信息：設置same-site屬性，same-site屬性有兩個值，Strict（全部的第三方請求都不能攜帶本網站的cookie）和Lax（連接能夠，可是form表單提交和ajax請求不行）

（2）本網站前端頁面添加驗證信息：使用驗證碼或者添加token驗證

　　驗證碼：當發起請求時，前端須要輸入本網站頁面的驗證碼信息，後端對驗證碼進行驗證，驗證碼正確纔會進行相關操做（存取數據等）

　　token驗證：a站前端將token存在當前頁面中（好比表單中的input隱藏域，meta標籤或者任何一個dom的屬性）和cookie中，當請求a站後端的時候，參數中帶上這個token字段，a站後端將參數中的token和cookie中的token作對比， 相同則驗證經過，不一樣則請求不合法

不論是驗證碼仍是token驗證，原理都是同樣的，在a站前端頁面加入驗證，當第三方網站請求a站後端時，即便能攜帶a站cookie，可是由於沒有通過a站的前端頁面從而拿不到驗證信息，也會致使請求失敗。

兩種防護的方法也有區別，驗證碼須要用戶去填寫，從而增長了用戶使用網站的複雜度，而token驗證在用戶無感知的狀況下就能夠實現，不影響用戶體驗。我我的理解，驗證碼驗證通常使用在須要提升用戶認知的場景，好比，登陸屢次失敗，修改我的信息（用戶名，密碼，綁定手機號等等），而一些獲取商品列表信息，搜索等接口，使用token比較合理。能夠看看咱們平時使用的這些網站，做參考～

（3）referer驗證：禁止來自第三方的請求

（4）使用post請求：有一個說法是「post請求比get請求更安全」，那這種說法對不對呢？實際上這種說法並不許確，對於CSRF攻擊來說，不論是post仍是get都能實現攻擊，區別只是post請求攻擊方須要構造一個form表單才能夠發起請求，比get請求（img的src， a標籤的href等等）的攻擊方式複雜了一些，可是並不能有效的阻止攻擊。

三、點擊劫持攻擊防護

（1）Javascript禁止內嵌：當網頁沒有被使用iframe內嵌時，top和window是相等的；當網頁被內嵌時，top和window是不相等的；能夠在本網站的頁面中添加以下判斷：

 

<script>
if (top.location != window.location) {
    //若是不相等，說明使用了iframe，可進行相關的操做
}
</script>

 

可是這種方式並非萬能的，由於iframe標籤中的屬性sandbox屬性是能夠禁用內嵌網頁的腳本的：

<iframe sandbox='allow-forms' src='...'></iframe>

 

（2）設置http響應頭 X-Frame-Options：有三個值 DENY（禁止內嵌） SAMEORIGIN（只容許同域名頁面內嵌） ALLOW-FROM（指定能夠內嵌的地址）

　　  能在全部的web服務器端預設好X-Frame-Options字段值是最理想的狀態。

（3）一些輔助手段，好比添加驗證碼，提升用戶的防範意識

3、總結

本文旨在對平時瞭解到的知識作一些總結和記錄，方便查閱和複習，描述不當之處，歡迎指出。

文中有些部分並未深刻展開，好比iframe的sandbox屬性（只適用於內嵌網頁是form提交的狀況，若是全部的請求都經過ajax來請求，而js腳本又被禁用的話，那就沒辦法實現點擊劫持了），有一些內容須要你本身動腦思考。

後續可能還會有補充，好比SQL注入部分，總之，今天先這樣啦～