[面試專題]前端須要知道的web安全知識

前端須要知道的web安全知識

標籤（空格分隔）： 未分類

---

安全

• [Doc] Crypto (加密)

• [Doc] TLS/SSL

• [Doc] HTTPS

• [Point] XSS

• [Point] CSRF

• [Point] 中間人攻擊

• [Point] Sql/Nosql 注入攻擊

Crypto

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

加密是如何保證用戶密碼的安全性?

在客戶端加密, 是增長傳輸的過程當中被第三方嗅探到密碼後破解的成本. 對於遊戲, 在客戶端加密是防止外掛/破解等. 在服務端加密 (如 md5) 是避免管理數據庫的 DBA 或者攻擊者攻擊數據庫以後直接拿到明文密碼, 從而提升安全性.

TLS/SSL

早期的網絡傳輸協議因爲只在大學內使用, 因此是默認互相信任的. 因此傳統的網絡通訊能夠說是沒有考慮網絡安全的. 早年的瀏覽器大廠網景公司爲了應對這個狀況設計了 SSL (Secure Socket Layer), SSL 的主要用途是:

1. 認證用戶和服務器, 確保數據發送到正確的客戶機和服務器;

2. 加密數據以防止數據中途被竊取;

3. 維護數據的完整性, 確保數據在傳輸過程當中不被改變.

存在三個特性:

• 機密性：SSL協議使用密鑰加密通訊數據

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

• 完整性：SSL協議會對傳送的數據進行完整性檢查

1999年, SSL 由於應用普遍, 已經成爲互聯網上的事實標準. IETF 就在那年把 SSL 標準化/強化. 標準化以後的名稱改成傳輸層安全協議 (Transport Layer Security, TLS). 不少相關的文章都把這二者並列稱呼 (TLS/SSL), 由於這二者能夠視做同一個東西的不一樣階段.

HTTPS

在網絡上, 每一個網站都在各自的服務器上, 想要確保你訪問的是一個正確的網站, 而且訪問到這個網站正確的數據 (沒有被劫持/篡改), 除了須要傳輸安全以外, 還須要安全的認證, 認證不能由目標網站進行, 不然惡意/釣魚網站也能夠本身說本身是對的, 因此爲了能在網絡上維護網絡之間的基本信任, 早期的大廠們協力推進了一項名爲 PKI 的基礎設施, 經過第三方來認證網站.

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

由 RA 統籌、審覈用戶的證書申請, 將證書申請送至 CA 處理後發出證書, 並將證書公告至 DS 中. 在使用證書的過程當中, 除了對證書的信任關係與證書自己的正確性作檢查外, 並透過產生和發佈證書廢止列表 (Certificate Revocation List, CRL) 對證書的狀態作確認檢查, 瞭解證書是否因某種緣由而遭廢棄. 證書就像是我的的身分證, 其內容包括證書序號、用戶名稱、公開金鑰 (Public Key) 、證書有效期限等.

在 TLS/SLL 中你可使用 OpenSSL 來生成 TLS/SSL 傳輸時用來認證的 public/private key. 不過這個 public/private key 是本身生成的, 而經過 PKI 基礎設施能夠得到權威的第三方證書 (key) 從而加密 HTTP 傳輸安全. 目前博客圈子裏比較流行的是 Let's Encrypt 簽發免費的 HTTPS 證書.

須要注意的是, 若是 PKI 受到攻擊, 那麼 HTTPS 也同樣不安全. 能夠參見 HTTPS 劫持 - 知乎討論 中的狀況, 證書由 CA 機構簽發, 通常瀏覽器遇到非權威的 CA 機構是會告警的 (參見 12306), 可是若是你在某些特殊的狀況下信任了某個未知機構/證書, 那麼也可能被劫持.

此外有的 CA 機構以郵件方式認證, 那麼當某個網站的郵件服務收到攻擊/滲透, 那麼攻擊者也可能以此從 CA 機構獲取權威的正確的證書.

XSS

跨站腳本 (Cross-Site Scripting, XSS) 是一種代碼注入方式, 爲了與 CSS 區分因此被稱做 XSS. 早期常見於網絡論壇, 原由是網站沒有對用戶的輸入進行嚴格的限制, 使得攻擊者能夠將腳本上傳到帖子讓其餘人瀏覽到有惡意腳本的頁面, 其注入方式很簡單包括但不限於 JavaScript / VBScript / CSS / Flash 等.

當其餘用戶瀏覽到這些網頁時, 就會執行這些惡意腳本, 對用戶進行 Cookie 竊取/會話劫持/釣魚欺騙等各類攻擊. 其原理, 如使用 js 腳本收集當前用戶環境的信息 (Cookie 等), 而後經過 img.src, Ajax, onclick/onload/onerror 事件等方式將用戶數據傳遞到攻擊者的服務器上. 釣魚欺騙則常見於使用腳本進行視覺欺騙, 構建假的惡意的 Button 覆蓋/替換真實的場景等狀況 (該狀況在用戶上傳 CSS 的時候也可能出現, 如早起淘寶網店裝修, 使用 CSS 拼接假的評分數據等覆蓋在真的評分數據上誤導用戶).

• 反射型XSS:非持久化，欺騙用戶去點擊連接,攻擊代碼包含在url中,被用戶點擊以後執行攻擊代碼.

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

• 防範與過濾

  • 輸入編碼過濾:對於每個輸入，在客戶端和服務器端驗證是否合法字符，長度是否合法，格式是否正確,對字符進行轉義.非法字符過濾.

  • 輸出編碼過濾:對全部要動態輸出到頁面的內容，進行相關的編碼和轉義.主要有HTML字符過濾和轉義,JS腳本轉義過濾.url轉義過濾.

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

CPS 策略

在百般無奈, 沒有統一解決方案的狀況下, 廠商們推出了 CPS 策略.

以 Node.js 爲例, 計算腳本的 hashes 值:

const crypto = require('crypto');

function getHashByCode(code, algorithm = 'sha256') {
  return algorithm + '-' + crypto.createHash(algorithm).update(code, 'utf8').digest("base64");
}

getHashByCode('console.log("hello world");'); // 'sha256-wxWy1+9LmiuOeDwtQyZNmWpT0jqCUikqaqVlJdtdh/0='

設置 CSP 頭:

content-security-policy: script-src 'sha256-wxWy1+9LmiuOeDwtQyZNmWpT0jqCUikqaqVlJdtdh/0='

<script>console.log('hello geemo')</script> <!-- 不執行 -->
<script>console.log('hello world');</script> <!-- 執行 -->

策略指令能夠參見 CSP Policy Directives以及阮一峯的博文, 屈大神的博文

CSRF

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

已知某站點 A 刪除的接口是 get 到某個地址, 並指定一個帖子的 id. 在網站 B 上組織一個刪除A站某文章的get請求. 而後A站用戶訪問B站,觸發該請求. 就能夠不知情的狀況下刪除某個帖子.

同源策略是最先用於防止 CSRF 的一種方式, 即關於跨站請求 (Cross-Site Request) 只有在同源/信任的狀況下才能夠請求. 可是若是一個網站羣, 在互相信任的狀況下, 某個網站出現了問題:

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

以上狀況下, 若是 c.public.com 上沒有預防 xss 等狀況, 使得攻擊者能夠基於此站對其餘信任的網站發起 CSRF 攻擊.

另外同源策略主要是瀏覽器來進行驗證的, 而且不一樣瀏覽器的實現又各自不一樣, 因此在某些瀏覽器上能夠直接繞過, 並且也能夠直接經過短信等方式直接繞過瀏覽器.

預防:

1. 在 HTTP 頭中自定義屬性並驗證

2. 檢查 CSRF token.

3. cookie中加入hash隨機數.

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

• Origin Header

• Referer Header

中間人攻擊

中間人 (Man-in-the-middle attack, MITM) 是指攻擊者與通信的兩端分別建立獨立的聯繫, 並交換其所收到的數據, 使通信的兩端認爲他們正在經過一個私密的鏈接與對方直接對話, 但事實上整個會話都被攻擊者徹底控制. 在中間人攻擊中, 攻擊者能夠攔截通信雙方的通話並插入新的內容.

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

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

不常見的還有強力的互相認證, 你確認他以後, 他也確認你一下; 延遲測試, 統計傳輸時間, 若是通信延遲太高則認爲可能存在第三方中間人; 等等.

SQL/NoSQL 注入

注入攻擊是指當所執行的一些操做中有部分由用戶傳入時, 用戶能夠將其惡意邏輯注入到操做中. 當你使用 eval, new Function 等方式執行的字符串中有用戶輸入的部分時, 就可能被注入攻擊. 上文中的 XSS 就屬於一種注入攻擊. 前面的章節中也提到過 Node.js 的 child_process.exec 因爲調用 bash 解析, 若是執行的命令中有部分屬於用戶輸入, 也可能被注入攻擊.

SQL

Sql 注入是網站常見的一種注入攻擊方式. 其緣由主要是因爲登陸時須要驗證用戶名/密碼, 其執行 sql 相似:

SELECT * FROM users WHERE usernae = 'myName' AND password = 'mySecret';

其中的用戶名和密碼屬於用戶輸入的部分, 那麼在未作檢查的狀況下, 用戶可能拼接惡意的字符串來達到其某種目的, 例如上傳密碼爲 '; DROP TABLE users; -- 使得最終執行的內容爲:

SELECT * FROM users WHERE usernae = 'myName' AND password = ''; DROP TABLE users; --';

其能實現的功能, 包括但不限於刪除數據 (經濟損失), 篡改數據 (密碼等), 竊取數據 (網站管理權限, 用戶數據) 等. 防治手段常見於:

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

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

• 過濾能夠拼接 SQL 的關鍵字符

• 對用戶輸入進行轉義

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

• 等...

NoSQL

看個簡單的狀況:

let {user, pass, age} = ctx.query;

db.collection.find({
  user, pass,
  $where: `this.age >= ${age}`
})

那麼這裏的 age 就能夠注入了. 另外 GET/POST 還能夠傳遞深層結構 (好比 ?name[0]=alan 傳遞上來), 經過 qs 之類的模塊解析後致使注入, 如 cnodejs 遭遇 mongodb 注入.

DDOS

DDoS即Distributed Denial of Service，分佈式拒絕服務。也就是攻擊者藉助或者利用服務器技術，將多個計算機（肉雞或殭屍機）聯合起來做爲攻擊平臺，對一個或者多個目標服務器，同一時間發送大量垃圾信息，或利用某種干擾信息的方式，致使目標服務器沒法及時響應正經常使用戶正常請求，或者直接致使目標服務器宕機，從而沒法爲正經常使用戶提供服務的一種攻擊行爲。

攻擊方式:

• 端口掃描攻擊

• ping洪水（flooding）攻擊

• SYN洪水（flooding）攻擊

• FTP跳轉攻擊

防範手段:

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

• 確保服務器採用最新系統，並打上安全補丁。

• 在服務器上刪除未使用的服務，關閉未使用的端口。

• 對於服務器上運行的網站，確保其打了最新的補丁，沒有安全漏洞。

• 隱藏服務器的真實IP地址