前端安全

一:加密安全

1、Crypto

Node.js 的?crypto?模塊封裝了諸多的加密功能, 包括 OpenSSL 的哈希、HMAC、加密、解密、簽名和驗證函數(shù)等.

在客戶端加密, 是增加傳輸?shù)倪^程中被第三方嗅探到密碼后破解的成本. 對于游戲, 在客戶端加密是防止外掛/破解等. 在服務端加密 (如 md5) 是避免管理數(shù)據(jù)庫的 DBA 或者攻擊者攻擊數(shù)據(jù)庫之后直接拿到明文密碼, 從而提高安全性.

2、TLS/SSL

SSL 的主要用途是:

認證用戶和服務器, 確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器;

加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取;

維護數(shù)據(jù)的完整性, 確保數(shù)據(jù)在傳輸過程中不被改變.

存在三個特性:

機密性:SSL協(xié)議使用密鑰加密通信數(shù)據(jù)

可靠性:服務器和客戶都會被認證, 客戶的認證是可選的

完整性:SSL協(xié)議會對傳送的數(shù)據(jù)進行完整性檢查

3、HTTPS

在網(wǎng)絡上, 每個網(wǎng)站都在各自的服務器上, 想要確保你訪問的是一個正確的網(wǎng)站, 并且訪問到這個網(wǎng)站正確的數(shù)據(jù) (沒有被劫持/篡改), 除了需要傳輸安全之外, 還需要安全的認證, 認證不能由目標網(wǎng)站進行, 否則惡意/釣魚網(wǎng)站也可以自己說自己是對的, 所以為了能在網(wǎng)絡上維護網(wǎng)絡之間的基本信任, 早期的大廠們合力推動了一項名為 PKI 的基礎設施, 通過第三方來認證網(wǎng)站.

公鑰基礎設施 (Public Key Infrastructure, PKI) 是一種遵循標準的, 利用公鑰加密技術(shù)為電子商務的開展提供一套安全基礎平臺的技術(shù)和規(guī)范. 其基礎建置包含認證中心 (Certification Authority, CA) 、注冊中心 (Register Authority, RA) 、目錄服務 (Directory Service, DS) 服務器.

由 RA 統(tǒng)籌、審核用戶的證書申請, 將證書申請送至 CA 處理后發(fā)出證書, 并將證書公告至 DS 中. 在使用證書的過程中, 除了對證書的信任關(guān)系與證書本身的正確性做檢查外, 并透過產(chǎn)生和發(fā)布證書廢止列表 (Certificate Revocation List, CRL) 對證書的狀態(tài)做確認檢查, 了解證書是否因某種原因而遭廢棄. 證書就像是個人的身分證, 其內(nèi)容包括證書序號、用戶名稱、公開金鑰 (Public Key) 、證書有效期限等.

在 TLS/SLL 中你可以使用 OpenSSL 來生成 TLS/SSL 傳輸時用來認證的 public/private key. 不過這個 public/private key 是自己生成的, 而通過 PKI 基礎設施可以獲得權(quán)威的第三方證書 (key) 從而加密 HTTP 傳輸安全. 目前博客圈子里比較流行的是?Let's Encrypt 簽發(fā)免費的 HTTPS 證書.

二:攻擊與防范

1、XSS攻擊

跨站腳本 (Cross-Site Scripting, XSS) 是一種代碼注入方式, 為了與 CSS 區(qū)分所以被稱作 XSS. 早期常見于網(wǎng)絡論壇, 起因是網(wǎng)站沒有對用戶的輸入進行嚴格的限制, 使得攻擊者可以將腳本上傳到帖子讓其他人瀏覽到有惡意腳本的頁面, 其注入方式很簡單包括但不限于 JavaScript / VBScript / CSS / Flash 等.

當其他用戶瀏覽到這些網(wǎng)頁時, 就會執(zhí)行這些惡意腳本, 對用戶進行 Cookie 竊取/會話劫持/釣魚欺騙等各種攻擊. 其原理, 如使用 js 腳本收集當前用戶環(huán)境的信息 (Cookie 等), 然后通過 img.src, Ajax, onclick/onload/onerror 事件等方式將用戶數(shù)據(jù)傳遞到攻擊者的服務器上. 釣魚欺騙則常見于使用腳本進行視覺欺騙, 構(gòu)建假的惡意的 Button 覆蓋/替換真實的場景等情況 (該情況在用戶上傳 CSS 的時候也可能出現(xiàn), 如早起淘寶網(wǎng)店裝修, 使用 CSS 拼接假的評分數(shù)據(jù)等覆蓋在真的評分數(shù)據(jù)上誤導用戶).

反射型XSS:非持久化,欺騙用戶去點擊鏈接,攻擊代碼包含在url中,被用戶點擊之后執(zhí)行攻擊代碼.

存儲型XSS:持久型,攻擊提交惡意代碼到服務器,服務器存儲該段代碼,這樣當其他用戶請求后,服務器返回gai'go'n并發(fā)給用戶,用戶瀏覽此類頁面時就可能受到攻擊。例如:惡意用戶的HTML或JS輸入服務器->進入數(shù)據(jù)庫->服務器響應時查詢數(shù)據(jù)庫->用戶瀏覽器。

DOM xss :DOM即文本對象模型,DOM通常代表在html、xhtml和xml中的對象,使用DOM可以允許程序和腳本動態(tài)的訪問和更新文檔的內(nèi)容、結(jié)構(gòu)和樣式。它不需要服務器解析響應的直接參與,觸發(fā)XSS靠的是瀏覽器端的DOM解析,可以認為完全是客戶端的事情。

防范與過濾

輸入編碼過濾:對于每一個輸入,在客戶端和服務器端驗證是否合法字符,長度是否合法,格式是否正確,對字符進行轉(zhuǎn)義.非法字符過濾.

輸出編碼過濾:對所有要動態(tài)輸出到頁面的內(nèi)容,進行相關(guān)的編碼和轉(zhuǎn)義.主要有HTML字符過濾和轉(zhuǎn)義,JS腳本轉(zhuǎn)義過濾.url轉(zhuǎn)義過濾.

設置http-only,避免攻擊腳本讀取cookie.

CPS 策略

在百般無奈, 沒有統(tǒng)一解決方案的情況下, 廠商們推出了 CPS 策略.

2、CSRF攻擊

跨站請求偽造 (Cross-Site Request Forgery) 是一種偽造跨站請求的攻擊方式. 例如利用你在 A 站 (攻擊目標) 的 cookie / 權(quán)限等, 在 B 站 (惡意/釣魚網(wǎng)站) 拼裝 A 站的請求.

已知某站點 A 刪除的接口是 get 到某個地址, 并指定一個帖子的 id. 在網(wǎng)站 B 上組織一個刪除A站某文章的get請求. 然后A站用戶訪問B站,觸發(fā)該請求. 就可以不知情的情況下刪除某個帖子.

同源策略是最早用于防止 CSRF 的一種方式, 即關(guān)于跨站請求 (Cross-Site Request) 只有在同源/信任的情況下才可以請求. 但是如果一個網(wǎng)站群, 在互相信任的情況下, 某個網(wǎng)站出現(xiàn)了問題:

a.public.com
b.public.com
c.public.com
...

以上情況下, 如果 c.public.com 上沒有預防 xss 等情況, 使得攻擊者可以基于此站對其他信任的網(wǎng)站發(fā)起 CSRF 攻擊.

另外同源策略主要是瀏覽器來進行驗證的, 并且不同瀏覽器的實現(xiàn)又各自不同, 所以在某些瀏覽器上可以直接繞過, 而且也可以直接通過短信等方式直接繞過瀏覽器.

CSRF的防御方式

檢測http referer是否是同域名,通常來講,用戶提交的請求,referer應該是來來自站內(nèi)地址,所以如果發(fā)現(xiàn)referer中地址異常,那么很可能是遭到了CSRF攻擊。

避免登錄的session長時間存儲在客戶端中。

關(guān)鍵請求使用驗證碼或者token機制。在一些十分關(guān)鍵的操作,比如交易付款環(huán)節(jié)。這種請求中,加入驗證碼,可以防止被惡意用戶攻擊。token機制也有一定的防御作用。具體來說就是服務器每次返回客戶端頁面的時候,在頁面中埋上一個token字段,例如?

之后,客戶端請求的時候帶上這個token,使用這個機制后,攻擊者也就很難發(fā)起CSRF攻擊了。

預防:

在 HTTP 頭中自定義屬性并驗證

檢查 CSRF token.

cookie中加入hash隨機數(shù).

通過檢查來過濾簡單的 CSRF 攻擊, 主要檢查一下兩個 header:

Origin Header

Referer Header

與 xss 區(qū)別

通常來說 CSRF 是由 XSS 實現(xiàn)的,CSRF 時常也被稱為 XSRF(CSRF 實現(xiàn)的方式還可以是直接通過命令行發(fā)起請求等)。

本質(zhì)上講,XSS 是代碼注入問題,CSRF 是 HTTP 問題。XSS 是內(nèi)容沒有過濾導致瀏覽器將攻擊者的輸入當代碼執(zhí)行。CSRF 則是因為瀏覽器在發(fā)送 HTTP 請求時候自動帶上 cookie,而一般網(wǎng)站的 session 都存在 cookie里面。

3、SQL/NoSQL 注入

注入攻擊是指當所執(zhí)行的一些操作中有部分由用戶傳入時, 用戶可以將其惡意邏輯注入到操作中. 當你使用 eval, new Function 等方式執(zhí)行的字符串中有用戶輸入的部分時, 就可能被注入攻擊. 上文中的 XSS 就屬于一種注入攻擊. 前面的章節(jié)中也提到過 Node.js 的 child_process.exec 由于調(diào)用 bash 解析, 如果執(zhí)行的命令中有部分屬于用戶輸入, 也可能被注入攻擊.

Sql 注入是網(wǎng)站常見的一種注入攻擊方式. 其原因主要是由于登錄時需要驗證用戶名/密碼, 其執(zhí)行 sql 類似:

防治手段常見于:

給表名/字段名加前綴 (避免被猜到)

報錯隱藏表信息 (避免被看到, 12306 早起就出現(xiàn)過的問題)

過濾可以拼接 SQL 的關(guān)鍵字符

對用戶輸入進行轉(zhuǎn)義

驗證用戶輸入的類型 (避免 limit, order by 等注入)

4、中間人攻擊

中間人 (Man-in-the-middle attack, MITM) 是指攻擊者與通訊的兩端分別創(chuàng)建獨立的聯(lián)系, 并交換其所收到的數(shù)據(jù), 使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話, 但事實上整個會話都被攻擊者完全控制. 在中間人攻擊中, 攻擊者可以攔截通訊雙方的通話并插入新的內(nèi)容.

目前比較常見的是在公共場所放置精心準備的免費 wifi, 劫持/監(jiān)控通過該 wifi 的流量. 或者攻擊路由器, 連上你家 wifi 攻破你家 wifi 之后在上面劫持流量等.

對于通信過程中的 MITM, 常見的方案是通過 PKI / TLS 預防, 及時是通過存在第三方中間人的 wifi 你通過 HTTPS 訪問的頁面依舊是安全的. 而 HTTP 協(xié)議是明文傳輸, 則沒有任何防護可言.

不常見的還有強力的互相認證, 你確認他之后, 他也確認你一下; 延遲測試, 統(tǒng)計傳輸時間, 如果通訊延遲過高則認為可能存在第三方中間人; 等等.

5、DDOS攻擊

DDoS即Distributed Denial of Service,分布式拒絕服務。也就是攻擊者借助或者利用服務器技術(shù),將多個計算機(肉雞或僵尸機)聯(lián)合起來作為攻擊平臺,對一個或者多個目標服務器,同一時間發(fā)送大量垃圾信息,或利用某種干擾信息的方式,導致目標服務器無法及時響應正常用戶正常請求,或者直接導致目標服務器宕機,從而無法為正常用戶提供服務的一種攻擊行為。

攻擊方式:

端口掃描攻擊

ping洪水(flooding)攻擊

SYN洪水(flooding)攻擊

FTP跳轉(zhuǎn)攻擊

防范手段:

保證服務器系統(tǒng)的安全,確保服務器軟件沒有任何漏洞,防止攻擊者入侵。

確保服務器采用最新系統(tǒng),并打上安全補丁。

在服務器上刪除未使用的服務,關(guān)閉未使用的端口。

對于服務器上運行的網(wǎng)站,確保其打了最新的補丁,沒有安全漏洞。

隱藏服務器的真實IP地址

三:HTTP劫持與對策

HTTP劫持嚴格上來說不能完全算前端安全的范疇。因為導致這種情況的主要是運營商。

先簡單解釋下HTTP劫持吧,當我們訪問頁面的時候,運營商在頁面的HTML代碼中,插入彈窗、廣告等HTML代碼,來獲取相應的利益。

針對這種情況,最好的解決方式也就是使用HTTPS,加密過后,他們就沒法插入廣告代碼了。

那么對于還沒有升級的情況,我們可以努力讓影響降到最低。

情況一:頁面被iframe嵌套了

這種情況還是比較簡單的。對于跨域iframe,我們是可以改變父頁面地址的

情況二:頁面多出了廣告的html代碼或者插入廣告的腳本

這種情況下,我們能做的有限。

一方面我們可以檢測是否有新增的html。監(jiān)控檢測判斷,發(fā)現(xiàn)是廣告就移除掉。

另一方面,對于使用document.write方法寫入的廣告,我們可以通過重寫document.write方法來達到刪除廣告的目的

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

  • 原文連接 https://jkchao.cn/article/59de0283c52d5a4ba98b1f0d X...
    三毛丶閱讀 921評論 0 5
  • 前言 “安全”是個很大的話題,各種安全問題的類型也是種類繁多。如果我們把安全問題按照所發(fā)生的區(qū)域來進行分類的話,那...
    莫小耿閱讀 1,036評論 0 2
  • ????前端安全一直是一個蠻嚴苛的問題,特別如果設計到money更是如此。了解前端安全,在平時的coding中主動...
    Johnson杰閱讀 672評論 0 6
  • http://www.91ri.org/tag/fuzz-bug 通常情況下,有三種方法被廣泛用來防御CSRF攻擊...
    jdyzm閱讀 4,395評論 0 5
  • 1.CSRF2.XSS基本概念攻擊原理防御措施 CSRF CSRF基本概念 CSRF通常稱為跨站請求偽造,英文名 ...
    noyanse閱讀 404評論 0 0

友情鏈接更多精彩內(nèi)容