1 of 30

Web應用系統安全 Ch5~8

游上德 / 2022-11-10

B L U E P L A N E T

2 of 30

目錄

  • Ch.5 API分析技巧
  • Ch.6 識別第三方元件
  • Ch.7 尋找應用系統架構的弱點
  • Ch.8 第一回合重點回顧

​

2

B L U E P L A N E T

3 of 30

Ch.5 API分析技巧

3

B L U E P L A N E T

4 of 30

REST API

  • 當今多數應用系統API採用REST或SOAP格式，現在REST變得更加歡迎。
  • 每個端點代表一個特定的資源而不是一個函式。

​

4

REST的HTTP動詞

用途

POST

新增

GET

讀取

PUT

更新/取代

PATCH

更新/修改

DELETE

刪除

REST架構支援的HTTP動詞

B L U E P L A N E T

5 of 30

REST API

  • 若發現許多類似下列的HTTP請求，可以肯定就是REST API：

​

​

  • 從每一次請求所發送的cookie及header，也可發現RESTful架構的跡象：

​

​

  • 另一項特徵是每個請求都會挾帶身分符記(token)，REST API是無狀態的。

​

5

GET api.mega-bank.com/users/1234

GET api.mega-bank.com/users/1234/payments

POST api.mega-bank.com/users/1234/payments

POST /users/1234/payments HTTP/1.1

Host: api.mega-bank.com

Autthorization: Bearer abc 21323

Content-Type: application/x-www-form-urlencoded

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko)

B L U E P L A N E T

6 of 30

「Option」動詞

  • HTTP的一個特殊的「Option」動詞，請求伺服器回報所支援的API動詞類型。
  • 一般來說，只在API特別公開OPTIONS時才會回報。

6

Curl –I –X OPTIONS https://api.mega-bank.com/users/1234

​

200 OK

Allow: HEAD, GET, PUT, DELETE, OPTIONS

B L U E P L A N E T

7 of 30

測試 – 蛛思/實告API的Options動詞回應

使用comman line下curl失敗不確定原本，感覺有可能是環境問題。

使用線上工具測試的結果蛛思及實告的api皆有回應：

7

猜測可能是Nginx預設為開啟（未證實），須另外手動設定才能夠關閉。

B L U E P L A N E T

8 of 30

偵查HTTP動詞

  • 在瀏覽器中看到的第一個API呼叫最有可能是（本書舉例）…

8

GET api.mega-bank.com/users/1234

可以將這個API端點擴展成以下API。在本書例子中有寫成腳本用程式暴力呼叫測試API，有興趣的人可自行翻閱。

GET api.mega-bank.com/users/1234

POST api.mega-bank.com/users/1234

PUT api.mega-bank.com/users/1234

PATCH api.mega-bank.com/users/1234

DELETE api.mega-bank.com/users/1234

B L U E P L A N E T

9 of 30

測試 - 實告API

9

B L U E P L A N E T

10 of 30

身份驗證機制

10

  • 範例 - Header訊息如下：

GET /homepage

HOST mega-bank.com

Authorization: Basic am9l0jEyMzQ

Content Type: application/json

透過Base64解碼可得

joe:1234

B L U E P L A N E T

11 of 30

常見的API形式 – O Auth 2.0為例

  • Discord

11

{

“response_type”: code,

“client_id”: id,

“scope”: [scope],

“state”: state,

“redirect_uri”: uri

}

  • O Auth 2.0公開規格

https://discordapp.com/api/oauth2/authorize?response_type=code&client_\id=157730590492196864&scope=identify%20guilds.\join&state=15773059ghq9183habn&redirect_uri=https%3A%2F%2Fnicememe.\website&prompt=consent

  • Facebook

GET https://graph.facebook.com/v4.0/oauth/access_token?

Client_id={app-id}

&redirect_uri={redirect-uri}

&client_secret={app-secret}

&code={code-parameter}

B L U E P L A N E T

12 of 30

偵查獨有的API形式

  • 了解某個欄位（變數）值的可能清單稱為解答空間，我們會希望盡可能縮小解答空間到可行的範圍。
  • 範例 – error code / error message
    • 401 未經授權
    • 400 錯誤的請求
    • publicProfile only accepts “auth” and ”noAuth” as params

​

12

B L U E P L A N E T

13 of 30

Ch.6 識別第三方元件

13

B L U E P L A N E T

14 of 30

通用漏洞披露(CVE)資料庫

  • 有時第三方元件裡的漏洞早已公告周知，只要到通用漏洞披露(CVE)資料庫就能找到歷史版本的攻擊手法

14

B L U E P L A N E T

15 of 30

檢測SPA框架

  • EmberJS

15

  • AngularJS
  • React
  • VueJS

> Ember.VERSION

< “3.2.2”

const elements = getAllAngularRootElements();

const version = elements[0].attributes[‘ng-version’];

  • 不過根據我自己的實測這個方式通常都不可行，推測現在大多SPA架構的網站多採用 webpack等工具進行打包，應該只有在採用較舊版本前端框架（比如AngularJS v1）、或者在 MPA (Muti-Page-Application)架構的網站比較有機會成功。

const version = React.version

const version = Vue.version

B L U E P L A N E T

16 of 30

檢測Javascript函式庫

16

B L U E P L A N E T

17 of 30

檢測CSS樣式庫

17

B L U E P L A N E T

18 of 30

後端框架/套件留下來的痕跡

  • 檢測標題 - 未適當設定或舊版本的套件會公開太多預設資訊

​

  • 預設的錯誤訊息和404網頁

18

大家一看就知道這個網站是用什麼框架做的吧？

X-Power-By: ASP.NET

Server: Microsoft-IIS/4.5

X-AspNet-Version: 4.0.25

B L U E P L A N E T

19 of 30

案例 – Ruby on Rails

  1. 偵查到此頁面為 Ruby on Rails的 404頁面。

​

​

  • 檢視HTML標籤，並比對 Ruby on Rails的 source code，不斷交叉比對之後判斷版本為 3.2.16和 4.2.8之間。
  • 碰巧，透過 「CVE資料庫」可查詢到 3.2.x 到 4.2.7版都存在 XSS漏洞，駭客可能可以藉由這個漏洞進入注入 Javascript。

19

B L U E P L A N E T

20 of 30

資料庫檢測

  • 透過發送到用戶端的錯誤訊息或者其它任何足跡，有機會可以檢測出資料庫。
  • 透過主鍵 (primary key)掃描是檢測的一種方式；除非開發者覆寫主鍵預設的產生方式，否則透過篩選足夠的網路請求就有機會確認資料庫類型。

​

20

B L U E P L A N E T

21 of 30

資料庫檢測 – MongoDB範例 (1)

MongoDB的預設鍵值為「_id」欄位，_id鍵值是使用雜湊演算法產生的12字元之十六進制字串，其演算法可以在文件裡看到，如下：

    • 用於產生這些ID的類別稱為 ObjectId
    • 每個 ID都是 12 Byte
    • 前 4 Byte代表自 Unix紀元以來的秒數(Timestamp)
    • 接下來的 5 Byte是隨機產生的
    • 最後 3 Btype 是用來初始亂數的計數器

​

「507f1f77bcf86cd799439011」就是 ObjectId的一個例子。

​

21

B L U E P L A N E T

22 of 30

資料庫檢測 – MongoDB範例 (2)

  • 從API請求中找到主鍵，例如：

​

​

  • 在中介資料 (metadata)或與使用者物件有關的資料裡：

22

GET users/:ID

PUT users, body = { id: ID }

GET users?id = ID

{

_id: ‘507f1f77bcf86cd799439011’,

username: ‘joe123’,

email: ‘joe123@my-email.com’,

role: ‘moderator’,

biography: ‘…’

}

B L U E P L A N E T

23 of 30

Ch.7 尋找應用系統架構的弱點

23

B L U E P L A N E T

24 of 30

偵查清單

  • 在整個偵查過程將得到的情報以某種形式記錄下來，將研究結果作成文件是不可或缺的。最好提供井然有序的說明，內容至少包括：
    • Web 應用系統使用的技術
    • 依照 HTTP動詞列出可用的 API端點
    • 列出 API端點形式（如果有）
    • Web 應用程式系統所包含的功能（如留言、身分驗證、訊息通知等）
    • Web 應系統使用的網域
    • 所有找到的組態資訊，例如內容安全性原則 (CSP)
    • 身份驗證 / Session管理機制

​

24

B L U E P L A N E T

25 of 30

系統架構安全性

  • 本書作者認為：多數漏洞源自設計不良的系統架構，而非不當的程式撰寫習慣。
  • 單一事件可能是程式撰寫不當造成，當出現許多漏洞時，就很可能是應用系統架構脆弱的信號。
  • 「 安全性高」的應用程式，是從實作之前及當下就融入安全條件；「安全性中」的應用程式，是在開發過程中加入安全防設，「全全性低」的則是不實作任何安全功能。

​

25

B L U E P L A N E T

26 of 30

案例 – XSS防護機制

  • 這個函式被套用在應用程式當中來防止 XSS攻擊，但是 unsafe參數預設是關閉的，此類函式的實作就顯得很重要
  • 雖然本書沒有寫，不過我個人以開發者的觀點，認為該函式應該把 unsafe參數拿掉（或預設為true），並把名稱設為 dangerouslyAppendToDom。

​

。

26

import { DOMPurify } from ‘../utils/DOMPurify’

​

// 使用：https://github.com/cure53/DOMPurify

Const appendToDom = function (data, selector, unsafe = false) {

const element = document.querySelector(selector)

​

if (unsafe) {

element.innerHTML = DOMPurify.sanitize(data)

} else {

element.innerText = data

}

}

B L U E P L A N E T

27 of 30

多層式安全

  • 在前面例子中（完整範例請詳閱本書），多個層次判斷可能發生 XSS風險的地方：
    • API POST
    • 資料庫寫入
    • 資料庫讀取
    • API GET
    • 用戶端讀取
  • 應用系統的安全性取決於架構中最薄弱的一環。如果開發人員在多個層面加入安全機制，即使在程式重構或加入新功能時，也可以降低對新的程式碼安全性不足所造成的風險。

27

B L U E P L A N E T

28 of 30

Ch.8 重點回顧

28

B L U E P L A N E T

29 of 30

第一回合重點回顧

  • 整理並記錄偵查結果是重要的，也建議寫下使用的偵查技術，最終將可掌握許多獨特的技術、框架、版本和方法。
  • 有效地記錄和組織你的偵查技術，日後才容易發展成自動化工具。

​

​

29

B L U E P L A N E T

30 of 30

Thx for listening

30

B L U E P L A N E T