前端程序員必須知道的 Web 漏洞，快來看看

原創(chuàng)2022-01-02 07:48·前端人隨著互聯(lián)網(wǎng)的發(fā)展，早已經(jīng)不是僅限于簡單的網(wǎng)頁或是社交，電商購物、銀行轉(zhuǎn)賬、企業(yè)管理等等。上次看到一個新聞，后臺程序員離職后，利用職位之便，每天還不斷的給自己轉(zhuǎn)賬，轉(zhuǎn)了好多次才被發(fā)現(xiàn)，想想這多可怕?；蛘邥`取重要的商業(yè)信息，所以 Web 安全也是非常值得注意的。

什么是 Web 安全?

黑客利用網(wǎng)絡(luò)操作系統(tǒng)的漏洞和 Web 服務器的 SQL 注入漏洞等，得到 Web 服務器的控制權(quán)，輕則篡改、刪除、添加數(shù)據(jù)，重則竊取重要的商業(yè)信息、轉(zhuǎn)賬等，更嚴重的就是在網(wǎng)頁中植入惡意代碼，使網(wǎng)站受到不可預期的侵害。

常見的攻擊可分為三類：XSS、CSRF、SQL注入。

1、XSS 攻擊

Cross Site Scripting 跨站腳本攻擊，為了與 CSS 區(qū)分，所以簡寫為 XSS 。

惡意攻擊給 Web 頁面植入惡意的 Script 代碼，當用戶瀏覽該網(wǎng)頁的時候，嵌入 Web 里面的 script 代碼會被執(zhí)行，從而達到攻擊的效果。

講直白點，就是惡意攻擊者通過在輸入框處添加惡意 script 代碼，用戶瀏覽網(wǎng)頁的時候執(zhí)行 script 代碼，從而達到惡意攻擊用戶的目的。

1.1、XSS 的危害

• 盜用各類賬號，然后進行數(shù)據(jù)各種任意操作。
• 控制企業(yè)數(shù)據(jù)，包括刪除、添加、篡改敏感信息等。
• 盜取具有商業(yè)價值信息。
• 強制發(fā)送電子郵件，獲取驗證碼。
• 控制受害者的機器向其他網(wǎng)站發(fā)起攻擊。

1.2、XSS 的攻擊類型

• 反射型 XSS 跨站腳本攻擊

發(fā)出請求時，XSS代碼會出現(xiàn)在 url 中，作為輸入提交到服務器端，服務器再返回給瀏覽器，然后瀏覽器解析執(zhí)行 XSS 代碼，這一過程像一次反射，所以稱之為反射型。

這種類型的攻擊，通常是把 XSS 攻擊代碼放入請求地址的 數(shù)據(jù)傳輸部分，如：

http://www.xxx.com?q=<script>alert("惡意腳本")</script>

或

http://www.xxx.com?n=<img sec="1 onerror=alert('惡意代碼')">

• 存儲型 XSS 跨站腳本攻擊

提交的 XSS 代碼會存儲在服務器端，如數(shù)據(jù)庫、內(nèi)存、文件系統(tǒng)內(nèi)，下次請求目標頁面時不再提交 XSS 代碼。

如在留言板輸入框位置添加 script 代碼或 html、css 代碼，把代碼為轉(zhuǎn)義，直接存入數(shù)據(jù)庫。

• 文檔型 XSS 跨站腳本攻擊

文檔型的 XSS 攻擊不會經(jīng)過服務器，作為中間人的角色，在數(shù)據(jù)傳輸過程中劫持到網(wǎng)絡(luò)數(shù)據(jù)包，然后修改里面的 html 文檔。

1.3、XSS 的防御措施

措施1：編碼。

對這些數(shù)據(jù)進行 html entity 編碼。客戶端和服務器端都需要進行轉(zhuǎn)義編碼。

<script>alert('惡意代碼')</script>

轉(zhuǎn)義后為：

<script>alert('惡意代碼')</script>

放入上邊的代碼中，還是會自動解析為上邊的代碼，所以放到外邊。

措施2：過濾。

移除用戶上傳的 DOM 屬性，如上邊的 onerror。

移除用戶上傳的 style、script、iframe 節(jié)點。

// 如
<div>
 <style>
  body { display:none } 
 </style>  
</div>

措施3：利用 CSP

瀏覽器中的內(nèi)容安全策略，就是決策瀏覽器加載哪些資源。

2、CSRF 攻擊

Cross site request forgery 跨站點請求偽造。

攻擊者誘導受害者進入第三方網(wǎng)站，向被攻擊網(wǎng)站發(fā)送跨站請求，利用被攻擊者在被攻擊網(wǎng)站已經(jīng)獲取的注冊憑證，繞過后臺的用戶驗證達到冒充用戶對攻擊網(wǎng)站進行的某種操作。

CSRF 攻擊特點：

• 并沒有劫持 cookie，只是偽造受害者的身份。
• 攻擊一般發(fā)起在第三方網(wǎng)站，被攻擊網(wǎng)站無法防止攻擊發(fā)生。
• 跨站請求可以是各種方式，如：圖片url、超鏈接、CORS、form提交。

2.1、CSRF 的危害

• 在社交網(wǎng)絡(luò)，網(wǎng)站被劫持之后，點擊會自動關(guān)注 + 分享。
• 銀行系統(tǒng)，被攻擊以后可以查詢余額，也可以自動轉(zhuǎn)賬。
• 電商類系統(tǒng)，如果被攻擊可以添加、刪除、清空購物車。

2.2、CSRF 的攻擊類型

• GET 類型攻擊

使用非常簡單，只需要一個 http 請求。

比如頁面中的一個圖片添加鏈接，還有 iframe、script ，最容易完成 CSFR 攻擊，且不易被用戶發(fā)現(xiàn)，隱蔽性超強。

由于 get 接口是最常見的一種 CSRF 攻擊類型，所以很多重要的接口不適用 get 方式，使用 post 一定程度上可以防止 CSRF 攻擊。

• POST 類型攻擊

這種類型的 SCRF 攻擊，通常使用的是一個自動提交的表單。簡單講就是偽造一個自動提交的表單，一旦訪問頁面時，表單就會自動提交。

如：

<form action="http://xxx.com/widthdraw" method="post">
 <input type="hidden" name="account" value="web" />
 <input type="hidden" name="psd" value="hacker" />
</form>

<script type="text/javascript">
 document.forms[0].submit()
</script>

• 鏈接類型的攻擊

比起前兩個，這個類型的比較少見，鏈接類型的攻擊必須要用戶點擊鏈接，才能觸發(fā)。

通常在論壇中發(fā)布的圖片嵌入惡意的鏈接，或以廣告的形式誘導用戶點擊中招。所以我們在郵箱中看到亂七八糟的廣告，盡量別點擊，防止遇到三方攻擊。

• 登錄 CSRF 攻擊方式

偽造一種新型的攻擊方式，用戶誤以為是在網(wǎng)站正常登錄，實際上是使用賬戶和密碼登錄到了黑客網(wǎng)站，這樣黑客可以監(jiān)聽到用戶的所有操作，甚至知道用戶的賬戶信息。

2.3、CSRF 的防御措施

措施1：檢查 http 頭部的 referer 信息

referer 包含在請求頭內(nèi)，表示請求接口的頁面來源。

服務端通過檢查 referer 信息，發(fā)現(xiàn)來源于外域時，就可以攔截請求，通過阻止不明外域的訪問，一定程度上可以減少攻擊。

措施2：使用一次性令牌

使用一次性令牌做身份識別，黑客是無法通過跨域拿到一次性令牌的，所以服務端可以通過判斷是否攜帶一次性令牌，就可以排除一部分的非法操作者。

措施3：使用驗證圖片

服務端生成一些文本和數(shù)字，在服務端保存這份信息，同時以圖片的形式在客戶端展現(xiàn)，讓用戶去合法填寫信息，當 CSRF 攻擊時，拿不到這個驗證碼的時候，無法向服務器提供這個信息，導致匹配失敗，從而識別它是非法攻擊者。

這個應用非常常見，之前登錄的時候，需要填寫圖形驗證碼。

現(xiàn)在滑動圖片驗證也非常常見。

3、SQL注入

SQL 注入，一般發(fā)生在注冊、評論、添加等，只有有用戶輸入的地方，就有可能發(fā)生 SQL 注入。SQL 注入是一種常見的 Web 安全漏洞，攻擊者會利用這個漏洞，可以訪問或修改數(shù)據(jù)，利用潛在的數(shù)據(jù)庫漏洞進行攻擊。

所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執(zhí)行惡意的SQL命令。具體來說，它是利用現(xiàn)有應用程序，將(惡意的)SQL命令注入到后臺數(shù)據(jù)庫引擎執(zhí)行的能力，它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫，而不是按照設(shè)計者意圖去執(zhí)行SQL語句。比如先前的很多影視網(wǎng)站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊.

3.1、SQL 注入危害

任意的賬號都可以登錄，可以進行任意的操作，粗暴點講，就是隨便來。

3.2、 SQL注入分類

• 數(shù)字型注入

當輸入的參數(shù)為整數(shù)時，則有可能存在數(shù)字型漏洞。

• 字符型注入

當輸入?yún)?shù)為字符串時，則可能存在字符型注入漏洞。數(shù)字型與字符型注入最大的區(qū)別在于：數(shù)字型不需要單引號閉合，而字符型一般需要使用單引號來閉合。

字符型注入最關(guān)鍵的是如何閉合 SQL 語句以及注釋多余的代碼。

• 其他類型

其實我覺得 SQL 注入只有兩種類型：數(shù)字型與字符型。很多人可能會說還有如：Cookie 注入、POST 注入、延時注入等。

的確如此，但這些類型的注入歸根結(jié)底也是數(shù)字型和字符型注入的不同展現(xiàn)形式或者注入的位置不同罷了。

以下是一些常見的注入叫法：

• POST注入：注入字段在 POST 數(shù)據(jù)中
• Cookie注入：注入字段在 Cookie 數(shù)據(jù)中
• 延時注入：使用數(shù)據(jù)庫延時特性注入
• 搜索注入：注入處為搜索的地方
• base64注入：注入字符串需要經(jīng)過 base64 加密

3.3、SQL注入的防范措施

凡是用戶輸入的地方，我們都應該防止黑客攻擊，永遠不要相信用戶的輸入。所以對應的防御措施分別有：

• 添加正則驗證，使用正則表達式過濾傳入的參數(shù)。
• 屏蔽敏感詞匯。
• 字符串過濾。

4、接口加密

前后端分離之后，前端每天都會接觸到很多接口。發(fā)送網(wǎng)絡(luò)請求的時候，有些接口就會使用 get 方法。最常見的傳參方式就是，直接在 url 地址后面加參數(shù)。

https://www.so.com/s?q='Web前端'

直接采用這種方式傳輸數(shù)據(jù)，如果數(shù)據(jù)被劫持或抓包工具偷走之后，就會直接被人盜取走，特別危險。若是采用接口加密，如下：

// 百度關(guān)鍵字查找示例
// 接口采用 get 方式
https://www.so.com/s?q=get%E4%BC%A0%E5%8F%82%E6%96%B9%E5%BC%8F&src=srp_suggst_revise&fr=se7_newtab_big&psid=014cd859f04a9ba923802a92f6821d44&eci=&nlpv=base_yc_52

上邊那個看不懂的一長串符號，正是經(jīng)過加密的數(shù)據(jù)。

接口加密就是將接口請求調(diào)用中傳遞的參數(shù)進行加密，目的就是為了保證接口請求中傳遞參數(shù)和返回的結(jié)果的安全性，一般比較敏感數(shù)據(jù)，如身份證、電話號碼、賬號、密碼等需要進行加密。

常見的加密方式：

• md5 加密
• base64 加密
• RSA 加密
• 對稱加密算法
• bcryptjs

加密方式較多，可以根據(jù)自己具體的需要和項目語言選擇其中一種。

加密之后的數(shù)據(jù)更安全，那我們能不能將接口所有的數(shù)據(jù)都進行加密呢?加密是非常消耗資源的，如果有大批量的數(shù)據(jù)都進行加密時，返回數(shù)據(jù)需要的時間就更長，會直接影響用戶體驗。所以我們進行加密時，只需要對敏感的重要的信息進行加密。