前端安全

Jsp發表於2018-05-28

一:加密安全

1、Crypto

Node.js 的 crypto 模組封裝了諸多的加密功能, 包括 OpenSSL 的雜湊、HMAC、加密、解密、簽名和驗證函式等.

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

2、TLS/SSL

SSL 的主要用途是:

  1. 認證使用者和伺服器, 確保資料傳送到正確的客戶機和伺服器;

  2. 加密資料以防止資料中途被竊取;

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

存在三個特性:

  • 機密性:SSL協議使用金鑰加密通訊資料

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

  • 完整性:SSL協議會對傳送的資料進行完整性檢查

3、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 證照.

二:攻擊與防範

1、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輸入伺服器->進入資料庫->伺服器響應時查詢資料庫->使用者瀏覽器。
  • DOM xss :DOM即文字物件模型,DOM通常代表在html、xhtml和xml中的物件,使用DOM可以允許程式和指令碼動態的訪問和更新文件的內容、結構和樣式。它不需要伺服器解析響應的直接參與,觸發XSS靠的是瀏覽器端的DOM解析,可以認為完全是客戶端的事情。

防範與過濾

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

  • 輸出編碼過濾:對所有要動態輸出到頁面的內容,進行相關的編碼和轉義.主要有HTML字元過濾和轉義,JS指令碼轉義過濾.url轉義過濾.

  • 設定http-only,避免攻擊指令碼讀取cookie.

CPS 策略

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


2、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 攻擊.

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

CSRF的防禦方式

  1. 檢測http referer是否是同域名,通常來講,使用者提交的請求,referer應該是來來自站內地址,所以如果發現referer中地址異常,那麼很可能是遭到了CSRF攻擊。

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

  3. 關鍵請求使用驗證碼或者token機制。在一些十分關鍵的操作,比如交易付款環節。這種請求中,加入驗證碼,可以防止被惡意使用者攻擊。token機制也有一定的防禦作用。具體來說就是伺服器每次返回客戶端頁面的時候,在頁面中埋上一個token欄位,例如 <input type=“hidden” name=“csrftoken” value=“abcd">

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

預防:

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

  2. 檢查 CSRF token.

  3. cookie中加入hash隨機數.

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

  • Origin Header

  • Referer Header

與 xss 區別

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

  • 本質上講,XSS 是程式碼注入問題,CSRF 是 HTTP 問題。XSS 是內容沒有過濾導致瀏覽器將攻擊者的輸入當程式碼執行。CSRF 則是因為瀏覽器在傳送 HTTP 請求時候自動帶上 cookie,而一般網站的 session 都存在 cookie裡面。

3、SQL/NoSQL 注入

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

Sql 注入是網站常見的一種注入攻擊方式. 其原因主要是由於登入時需要驗證使用者名稱/密碼, 其執行 sql 類似:

防治手段常見於:

  • 給表名/欄位名加字首 (避免被猜到)

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

  • 過濾可以拼接 SQL 的關鍵字元

  • 對使用者輸入進行轉義

  • 驗證使用者輸入的型別 (避免 limit, order by 等注入)

4、中間人攻擊

中間人 (Man-in-the-middle attack, MITM) 是指攻擊者與通訊的兩端分別建立獨立的聯絡, 並交換其所收到的資料, 使通訊的兩端認為他們正在通過一個私密的連線與對方直接對話, 但事實上整個會話都被攻擊者完全控制. 在中間人攻擊中, 攻擊者可以攔截通訊雙方的通話並插入新的內容.

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

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

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

5、DDOS攻擊

DDoS即Distributed Denial of Service,分散式拒絕服務。也就是攻擊者藉助或者利用伺服器技術,將多個計算機(肉雞或殭屍機)聯合起來作為攻擊平臺,對一個或者多個目標伺服器,同一時間傳送大量垃圾資訊,或利用某種干擾資訊的方式,導致目標伺服器無法及時響應正常使用者正常請求,或者直接導致目標伺服器當機,從而無法為正常使用者提供服務的一種攻擊行為。

攻擊方式:

  • 埠掃描攻擊

  • ping洪水(flooding)攻擊

  • SYN洪水(flooding)攻擊

  • FTP跳轉攻擊

防範手段:

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

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

  • 在伺服器上刪除未使用的服務,關閉未使用的埠。

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

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

三:HTTP劫持與對策

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

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

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

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

情況一:頁面被iframe巢狀了

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

情況二:頁面多出了廣告的html程式碼或者插入廣告的指令碼

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

一方面我們可以檢測是否有新增的html。監控檢測判斷,發現是廣告就移除掉。

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


相關文章