一：加密安全

1嫩挤、Crypto

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

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

2车伞、TLS/SSL

SSL 的主要用途是:

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

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

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

存在三個(gè)特性:

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

可靠性：服務(wù)器和客戶(hù)都會(huì)被認(rèn)證, 客戶(hù)的認(rèn)證是可選的

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

3择懂、HTTPS

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

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

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

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

二：攻擊與防范

1蹦哼、XSS攻擊

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

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

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

存儲(chǔ)型XSS:持久型,攻擊提交惡意代碼到服務(wù)器要糊，服務(wù)器存儲(chǔ)該段代碼,這樣當(dāng)其他用戶(hù)請(qǐng)求后纲熏，服務(wù)器返回gai'go'n并發(fā)給用戶(hù)，用戶(hù)瀏覽此類(lèi)頁(yè)面時(shí)就可能受到攻擊锄俄。例如:惡意用戶(hù)的HTML或JS輸入服務(wù)器->進(jìn)入數(shù)據(jù)庫(kù)->服務(wù)器響應(yīng)時(shí)查詢(xún)數(shù)據(jù)庫(kù)->用戶(hù)瀏覽器局劲。

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

防范與過(guò)濾

輸入編碼過(guò)濾:對(duì)于每一個(gè)輸入谈跛，在客戶(hù)端和服務(wù)器端驗(yàn)證是否合法字符，長(zhǎng)度是否合法塑陵，格式是否正確,對(duì)字符進(jìn)行轉(zhuǎn)義.非法字符過(guò)濾.

輸出編碼過(guò)濾:對(duì)所有要?jiǎng)討B(tài)輸出到頁(yè)面的內(nèi)容感憾，進(jìn)行相關(guān)的編碼和轉(zhuǎn)義.主要有HTML字符過(guò)濾和轉(zhuǎn)義,JS腳本轉(zhuǎn)義過(guò)濾.url轉(zhuǎn)義過(guò)濾.

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

CPS 策略

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

2、CSRF攻擊

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

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

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

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

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

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

CSRF的防御方式

檢測(cè)http referer是否是同域名令花，通常來(lái)講阻桅，用戶(hù)提交的請(qǐng)求，referer應(yīng)該是來(lái)來(lái)自站內(nèi)地址兼都，所以如果發(fā)現(xiàn)referer中地址異常嫂沉，那么很可能是遭到了CSRF攻擊。

避免登錄的session長(zhǎng)時(shí)間存儲(chǔ)在客戶(hù)端中扮碧。

關(guān)鍵請(qǐng)求使用驗(yàn)證碼或者token機(jī)制趟章。在一些十分關(guān)鍵的操作，比如交易付款環(huán)節(jié)慎王。這種請(qǐng)求中蚓土，加入驗(yàn)證碼，可以防止被惡意用戶(hù)攻擊赖淤。token機(jī)制也有一定的防御作用蜀漆。具體來(lái)說(shuō)就是服務(wù)器每次返回客戶(hù)端頁(yè)面的時(shí)候，在頁(yè)面中埋上一個(gè)token字段咱旱，例如?

之后确丢，客戶(hù)端請(qǐng)求的時(shí)候帶上這個(gè)token绷耍，使用這個(gè)機(jī)制后，攻擊者也就很難發(fā)起CSRF攻擊了蠕嫁。

預(yù)防:

在 HTTP 頭中自定義屬性并驗(yàn)證

檢查 CSRF token.

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

通過(guò)檢查來(lái)過(guò)濾簡(jiǎn)單的 CSRF 攻擊, 主要檢查一下兩個(gè) header:

Origin Header

Referer Header

與 xss 區(qū)別

通常來(lái)說(shuō) CSRF 是由 XSS 實(shí)現(xiàn)的锨天，CSRF 時(shí)常也被稱(chēng)為 XSRF（CSRF 實(shí)現(xiàn)的方式還可以是直接通過(guò)命令行發(fā)起請(qǐng)求等）。

本質(zhì)上講剃毒，XSS 是代碼注入問(wèn)題病袄，CSRF 是 HTTP 問(wèn)題。XSS 是內(nèi)容沒(méi)有過(guò)濾導(dǎo)致瀏覽器將攻擊者的輸入當(dāng)代碼執(zhí)行赘阀。CSRF 則是因?yàn)闉g覽器在發(fā)送 HTTP 請(qǐng)求時(shí)候自動(dòng)帶上 cookie益缠，而一般網(wǎng)站的 session 都存在 cookie里面。

3基公、SQL/NoSQL 注入

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

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

防治手段常見(jiàn)于:

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

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

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

對(duì)用戶(hù)輸入進(jìn)行轉(zhuǎn)義

驗(yàn)證用戶(hù)輸入的類(lèi)型 (避免 limit, order by 等注入)

4幅慌、中間人攻擊

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

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

對(duì)于通信過(guò)程中的 MITM, 常見(jiàn)的方案是通過(guò) PKI / TLS 預(yù)防, 及時(shí)是通過(guò)存在第三方中間人的 wifi 你通過(guò) HTTPS 訪問(wèn)的頁(yè)面依舊是安全的. 而 HTTP 協(xié)議是明文傳輸, 則沒(méi)有任何防護(hù)可言.

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

5、DDOS攻擊

DDoS即Distributed Denial of Service轰豆，分布式拒絕服務(wù)胰伍。也就是攻擊者借助或者利用服務(wù)器技術(shù)，將多個(gè)計(jì)算機(jī)（肉雞或僵尸機(jī)）聯(lián)合起來(lái)作為攻擊平臺(tái)酸休，對(duì)一個(gè)或者多個(gè)目標(biāo)服務(wù)器骂租，同一時(shí)間發(fā)送大量垃圾信息，或利用某種干擾信息的方式斑司，導(dǎo)致目標(biāo)服務(wù)器無(wú)法及時(shí)響應(yīng)正常用戶(hù)正常請(qǐng)求渗饮，或者直接導(dǎo)致目標(biāo)服務(wù)器宕機(jī)，從而無(wú)法為正常用戶(hù)提供服務(wù)的一種攻擊行為宿刮。

攻擊方式:

端口掃描攻擊

ping洪水（flooding）攻擊

SYN洪水（flooding）攻擊

FTP跳轉(zhuǎn)攻擊

防范手段:

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

確保服務(wù)器采用最新系統(tǒng)僵缺，并打上安全補(bǔ)丁胡桃。

在服務(wù)器上刪除未使用的服務(wù)，關(guān)閉未使用的端口磕潮。

對(duì)于服務(wù)器上運(yùn)行的網(wǎng)站标捺，確保其打了最新的補(bǔ)丁，沒(méi)有安全漏洞揉抵。

隱藏服務(wù)器的真實(shí)IP地址

三：HTTP劫持與對(duì)策

HTTP劫持嚴(yán)格上來(lái)說(shuō)不能完全算前端安全的范疇。因?yàn)閷?dǎo)致這種情況的主要是運(yùn)營(yíng)商嗤疯。

先簡(jiǎn)單解釋下HTTP劫持吧冤今，當(dāng)我們?cè)L問(wèn)頁(yè)面的時(shí)候，運(yùn)營(yíng)商在頁(yè)面的HTML代碼中茂缚，插入彈窗戏罢、廣告等HTML代碼屋谭，來(lái)獲取相應(yīng)的利益。

針對(duì)這種情況龟糕，最好的解決方式也就是使用HTTPS桐磁，加密過(guò)后，他們就沒(méi)法插入廣告代碼了讲岁。

那么對(duì)于還沒(méi)有升級(jí)的情況我擂，我們可以努力讓影響降到最低。

情況一：頁(yè)面被iframe嵌套了

這種情況還是比較簡(jiǎn)單的缓艳。對(duì)于跨域iframe校摩，我們是可以改變父頁(yè)面地址的

情況二：頁(yè)面多出了廣告的html代碼或者插入廣告的腳本

這種情況下，我們能做的有限阶淘。

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

另一方面坤塞，對(duì)于使用document.write方法寫(xiě)入的廣告，我們可以通過(guò)重寫(xiě)document.write方法來(lái)達(dá)到刪除廣告的目的