建站
咨詢
售后
建站咨詢
新聞中心
原創(chuàng)2022-01-02 07:48·前端人隨著互聯(lián)網(wǎng)的發(fā)展，早已經(jīng)不是僅限于簡(jiǎn)單的網(wǎng)頁或是社交，電商購物、銀行轉(zhuǎn)賬、企業(yè)管理等等。上次看到一個(gè)新聞，后臺(tái)程序員離職后，利用職位之便，每天還不斷的給自己轉(zhuǎn)賬，轉(zhuǎn)了好多次才被發(fā)現(xiàn)，想想這多可怕?；蛘邥?huì)竊取重要的商業(yè)信息，所以 Web 安全也是非常值得注意的。
什么是 Web 安全?
黑客利用網(wǎng)絡(luò)操作系統(tǒng)的漏洞和 Web 服務(wù)器的 SQL 注入漏洞等，得到 Web 服務(wù)器的控制權(quán)，輕則篡改、刪除、添加數(shù)據(jù)，重則竊取重要的商業(yè)信息、轉(zhuǎn)賬等，更嚴(yán)重的就是在網(wǎng)頁中植入惡意代碼，使網(wǎng)站受到不可預(yù)期的侵害。
常見的攻擊可分為三類：XSS、CSRF、SQL注入。
1、XSS 攻擊
Cross Site Scripting 跨站腳本攻擊，為了與 CSS 區(qū)分，所以簡(jiǎn)寫為 XSS 。
惡意攻擊給 Web 頁面植入惡意的 Script 代碼，當(dāng)用戶瀏覽該網(wǎng)頁的時(shí)候，嵌入 Web 里面的 script 代碼會(huì)被執(zhí)行，從而達(dá)到攻擊的效果。
講直白點(diǎn)，就是惡意攻擊者通過在輸入框處添加惡意 script 代碼，用戶瀏覽網(wǎng)頁的時(shí)候執(zhí)行 script 代碼，從而達(dá)到惡意攻擊用戶的目的。
1.1、XSS 的危害
- 盜用各類賬號(hào)，然后進(jìn)行數(shù)據(jù)各種任意操作。
- 控制企業(yè)數(shù)據(jù)，包括刪除、添加、篡改敏感信息等。
- 盜取具有商業(yè)價(jià)值信息。
- 強(qiáng)制發(fā)送電子郵件，獲取驗(yàn)證碼。
- 控制受害者的機(jī)器向其他網(wǎng)站發(fā)起攻擊。
1.2、XSS 的攻擊類型
- 反射型 XSS 跨站腳本攻擊
發(fā)出請(qǐng)求時(shí)，XSS代碼會(huì)出現(xiàn)在 url 中，作為輸入提交到服務(wù)器端，服務(wù)器再返回給瀏覽器，然后瀏覽器解析執(zhí)行 XSS 代碼，這一過程像一次反射，所以稱之為反射型。
這種類型的攻擊，通常是把 XSS 攻擊代碼放入請(qǐng)求地址的 數(shù)據(jù)傳輸部分，如：
http://www.xxx.com?q=
或
http://www.xxx.com?n=
- 存儲(chǔ)型 XSS 跨站腳本攻擊
提交的 XSS 代碼會(huì)存儲(chǔ)在服務(wù)器端，如數(shù)據(jù)庫、內(nèi)存、文件系統(tǒng)內(nèi)，下次請(qǐng)求目標(biāo)頁面時(shí)不再提交 XSS 代碼。
如在留言板輸入框位置添加 script 代碼或 html、css 代碼，把代碼為轉(zhuǎn)義，直接存入數(shù)據(jù)庫。
- 文檔型 XSS 跨站腳本攻擊
文檔型的 XSS 攻擊不會(huì)經(jīng)過服務(wù)器，作為中間人的角色，在數(shù)據(jù)傳輸過程中劫持到網(wǎng)絡(luò)數(shù)據(jù)包，然后修改里面的 html 文檔。
1.3、XSS 的防御措施
措施1：編碼。
對(duì)這些數(shù)據(jù)進(jìn)行 html entity 編碼。客戶端和服務(wù)器端都需要進(jìn)行轉(zhuǎn)義編碼。
轉(zhuǎn)義后為：
放入上邊的代碼中，還是會(huì)自動(dòng)解析為上邊的代碼，所以放到外邊。
措施2：過濾。
移除用戶上傳的 DOM 屬性，如上邊的 onerror。
移除用戶上傳的 style、script、iframe 節(jié)點(diǎn)。
// 如
措施3：利用 CSP
瀏覽器中的內(nèi)容安全策略，就是決策瀏覽器加載哪些資源。
2、CSRF 攻擊
Cross site request forgery 跨站點(diǎn)請(qǐng)求偽造。
攻擊者誘導(dǎo)受害者進(jìn)入第三方網(wǎng)站，向被攻擊網(wǎng)站發(fā)送跨站請(qǐng)求，利用被攻擊者在被攻擊網(wǎng)站已經(jīng)獲取的注冊(cè)憑證，繞過后臺(tái)的用戶驗(yàn)證達(dá)到冒充用戶對(duì)攻擊網(wǎng)站進(jìn)行的某種操作。
CSRF 攻擊特點(diǎn)：
- 并沒有劫持 cookie，只是偽造受害者的身份。
- 攻擊一般發(fā)起在第三方網(wǎng)站，被攻擊網(wǎng)站無法防止攻擊發(fā)生。
- 跨站請(qǐng)求可以是各種方式，如：圖片url、超鏈接、CORS、form提交。
2.1、CSRF 的危害
- 在社交網(wǎng)絡(luò)，網(wǎng)站被劫持之后，點(diǎn)擊會(huì)自動(dòng)關(guān)注 + 分享。
- 銀行系統(tǒng)，被攻擊以后可以查詢余額，也可以自動(dòng)轉(zhuǎn)賬。
- 電商類系統(tǒng)，如果被攻擊可以添加、刪除、清空購物車。
2.2、CSRF 的攻擊類型
- GET 類型攻擊
使用非常簡(jiǎn)單，只需要一個(gè) http 請(qǐng)求。
比如頁面中的一個(gè)圖片添加鏈接，還有 iframe、script ，最容易完成 CSFR 攻擊，且不易被用戶發(fā)現(xiàn)，隱蔽性超強(qiáng)。
由于 get 接口是最常見的一種 CSRF 攻擊類型，所以很多重要的接口不適用 get 方式，使用 post 一定程度上可以防止 CSRF 攻擊。
- POST 類型攻擊
這種類型的 SCRF 攻擊，通常使用的是一個(gè)自動(dòng)提交的表單。簡(jiǎn)單講就是偽造一個(gè)自動(dòng)提交的表單，一旦訪問頁面時(shí)，表單就會(huì)自動(dòng)提交。
如：
- 鏈接類型的攻擊
比起前兩個(gè)，這個(gè)類型的比較少見，鏈接類型的攻擊必須要用戶點(diǎn)擊鏈接，才能觸發(fā)。
通常在論壇中發(fā)布的圖片嵌入惡意的鏈接，或以廣告的形式誘導(dǎo)用戶點(diǎn)擊中招。所以我們?cè)卩]箱中看到亂七八糟的廣告，盡量別點(diǎn)擊，防止遇到三方攻擊。
- 登錄 CSRF 攻擊方式
偽造一種新型的攻擊方式，用戶誤以為是在網(wǎng)站正常登錄，實(shí)際上是使用賬戶和密碼登錄到了黑客網(wǎng)站，這樣黑客可以監(jiān)聽到用戶的所有操作，甚至知道用戶的賬戶信息。
2.3、CSRF 的防御措施
措施1：檢查 http 頭部的 referer 信息
referer 包含在請(qǐng)求頭內(nèi)，表示請(qǐng)求接口的頁面來源。
服務(wù)端通過檢查 referer 信息，發(fā)現(xiàn)來源于外域時(shí)，就可以攔截請(qǐng)求，通過阻止不明外域的訪問，一定程度上可以減少攻擊。
措施2：使用一次性令牌
使用一次性令牌做身份識(shí)別，黑客是無法通過跨域拿到一次性令牌的，所以服務(wù)端可以通過判斷是否攜帶一次性令牌，就可以排除一部分的非法操作者。
措施3：使用驗(yàn)證圖片
服務(wù)端生成一些文本和數(shù)字，在服務(wù)端保存這份信息，同時(shí)以圖片的形式在客戶端展現(xiàn)，讓用戶去合法填寫信息，當(dāng) CSRF 攻擊時(shí)，拿不到這個(gè)驗(yàn)證碼的時(shí)候，無法向服務(wù)器提供這個(gè)信息，導(dǎo)致匹配失敗，從而識(shí)別它是非法攻擊者。
這個(gè)應(yīng)用非常常見，之前登錄的時(shí)候，需要填寫圖形驗(yàn)證碼。
現(xiàn)在滑動(dòng)圖片驗(yàn)證也非常常見。
3、SQL注入
SQL 注入，一般發(fā)生在注冊(cè)、評(píng)論、添加等，只有有用戶輸入的地方，就有可能發(fā)生 SQL 注入。SQL 注入是一種常見的 Web 安全漏洞，攻擊者會(huì)利用這個(gè)漏洞，可以訪問或修改數(shù)據(jù)，利用潛在的數(shù)據(jù)庫漏洞進(jìn)行攻擊。
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。具體來說，它是利用現(xiàn)有應(yīng)用程序，將(惡意的)SQL命令注入到后臺(tái)數(shù)據(jù)庫引擎執(zhí)行的能力，它可以通過在Web表單中輸入(惡意)SQL語句得到一個(gè)存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫，而不是按照設(shè)計(jì)者意圖去執(zhí)行SQL語句。比如先前的很多影視網(wǎng)站泄露VIP會(huì)員密碼大多就是通過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊.
3.1、SQL 注入危害
任意的賬號(hào)都可以登錄，可以進(jìn)行任意的操作，粗暴點(diǎn)講，就是隨便來。
3.2、 SQL注入分類
- 數(shù)字型注入
當(dāng)輸入的參數(shù)為整數(shù)時(shí)，則有可能存在數(shù)字型漏洞。
- 字符型注入
當(dāng)輸入?yún)?shù)為字符串時(shí)，則可能存在字符型注入漏洞。數(shù)字型與字符型注入最大的區(qū)別在于：數(shù)字型不需要單引號(hào)閉合，而字符型一般需要使用單引號(hào)來閉合。
字符型注入最關(guān)鍵的是如何閉合 SQL 語句以及注釋多余的代碼。
- 其他類型
其實(shí)我覺得 SQL 注入只有兩種類型：數(shù)字型與字符型。很多人可能會(huì)說還有如：Cookie 注入、POST 注入、延時(shí)注入等。
的確如此，但這些類型的注入歸根結(jié)底也是數(shù)字型和字符型注入的不同展現(xiàn)形式或者注入的位置不同罷了。
以下是一些常見的注入叫法：
- POST注入：注入字段在 POST 數(shù)據(jù)中
- Cookie注入：注入字段在 Cookie 數(shù)據(jù)中
- 延時(shí)注入：使用數(shù)據(jù)庫延時(shí)特性注入
- 搜索注入：注入處為搜索的地方
- base64注入：注入字符串需要經(jīng)過 base64 加密
3.3、SQL注入的防范措施
凡是用戶輸入的地方，我們都應(yīng)該防止黑客攻擊，永遠(yuǎn)不要相信用戶的輸入。所以對(duì)應(yīng)的防御措施分別有：
- 添加正則驗(yàn)證，使用正則表達(dá)式過濾傳入的參數(shù)。
- 屏蔽敏感詞匯。
- 字符串過濾。
4、接口加密
前后端分離之后，前端每天都會(huì)接觸到很多接口。發(fā)送網(wǎng)絡(luò)請(qǐng)求的時(shí)候，有些接口就會(huì)使用 get 方法。最常見的傳參方式就是，直接在 url 地址后面加參數(shù)。
https://www.so.com/s?q='Web前端'
直接采用這種方式傳輸數(shù)據(jù)，如果數(shù)據(jù)被劫持或抓包工具偷走之后，就會(huì)直接被人盜取走，特別危險(xiǎn)。若是采用接口加密，如下：
// 百度關(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
上邊那個(gè)看不懂的一長(zhǎng)串符號(hào)，正是經(jīng)過加密的數(shù)據(jù)。
接口加密就是將接口請(qǐng)求調(diào)用中傳遞的參數(shù)進(jìn)行加密，目的就是為了保證接口請(qǐng)求中傳遞參數(shù)和返回的結(jié)果的安全性，一般比較敏感數(shù)據(jù)，如身份證、電話號(hào)碼、賬號(hào)、密碼等需要進(jìn)行加密。
常見的加密方式：
- md5 加密
- base64 加密
- RSA 加密
- 對(duì)稱加密算法
- bcryptjs
加密方式較多，可以根據(jù)自己具體的需要和項(xiàng)目語言選擇其中一種。
加密之后的數(shù)據(jù)更安全，那我們能不能將接口所有的數(shù)據(jù)都進(jìn)行加密呢?加密是非常消耗資源的，如果有大批量的數(shù)據(jù)都進(jìn)行加密時(shí)，返回?cái)?shù)據(jù)需要的時(shí)間就更長(zhǎng)，會(huì)直接影響用戶體驗(yàn)。所以我們進(jìn)行加密時(shí)，只需要對(duì)敏感的重要的信息進(jìn)行加密。
當(dāng)前標(biāo)題：前端程序員必須知道的Web漏洞，快來看看
本文鏈接：http://www.fisionsoft.com.cn/article/djjdpps.html
