# 12/29 Security issues about chatbots

# 聊天機器人資訊安全-技術漏洞

## webhook

1. 甚麼是webhook，與API差異

webhook是有效率的雙向溝通方法，當事件(訊息、加入、離開等)發生時，Line會將聊天事件發送往已經設定好的webhook網址，主動告知機器人事件發生了

若機器人不透過webhook的溝通模式時，我們必須時時刻刻都去向line平台詢問(API)，目前是否有事件發生，但相較事件發生會得到主動告知的方法，是非常沒效率且消耗資源的方法

2. Webhook Http vs Https

事件發生時，會將此事件詳細資訊以及加密訊息傳入webhook網址，若使用http協議，傳送時經過的路徑都可以看到訊息內容，甚至可以透過加密訊息複製一份偽裝的訊息至webhook網址

故需使用Https加密，關於https這邊不多贅述

3. 相關風險

1. 若webhook URL被猜到時
* 當webhook server與web server沒有分開時，惡意使用者可運用字典法掃描某服務已公開在網際網路上的hostname或是domain下的path，若POST任意訊息過去得到回傳非400時，就可猜測此為webhook url
(如 未加密的版本控制或Line Liff的出現使得許多webhook url接暴露於網際網路中)

* 導致
1. D-Dos (過載)
2. 偽造訊息 (詳見驗證篇章)

* 補充
由於webhook Url不是一般的web型態，其實用自簽的不安全SSL也可以建立https+IP的網址，印象中Line等聊天機器人平台可接受IP網址的webhook URL (須再驗證 簽SSL有點麻煩) ，但依據上述介紹，IP直接作為webhook更容易被掃瞄到，詳見下方防範章節

4. 防範

1. 用Serverless服務建立機器人，將可利用第三方雲端服務擋住惡意掃描，也同時可得到非常長不易猜測的https網址
2. 將多次嘗試404的ip封鎖，但此方法沒有第三方防禦強
3. 不使用常見的網址路徑，避開字典法掃描，以及較長的URL Path亂數保護

5. 案例
[**Phishing Attacks**](https://trello.com/c/n1rpPS0w/52-slack-webhook-issues)
[slack webhook attack](https://www.darkreading.com/cloud/slacks-incoming-webhooks-can-be-weaponized-in-phishing-attacks/d/d-id/1337573)

## 偽造訊息

### [LINE BOT 驗證機制](https://trello.com/c/iLYTJaqM/9-line)
#### 1. HMAC
* **介紹**

HMAC (Hash-based message authentication code) 是一種訊息驗證機制，可以確保傳遞訊息的完整性 (integrity) 和傳送人是否正確，HMAC 支援多種雜湊演算法 (MD5、SHA-256)，並藉由 hash 要傳遞的 message(request body) 和 secret key 來產生 signature 。

當接收方接收到 傳送方 (例如：LINE platform) 傳送的 request body 和 signature 後，會透過接收到的 request body + 持有的 secret key 進行 hash 產生 signature 。

最後再將兩組 signature 進行比較，如果兩者不相同，代表傳遞的訊息有被竄改過

此方法常用應用於[博弈相關程式](https://patents.google.com/patent/CN106552420A/zh)
將答案結果(request body)配合一組隨機字符串(Channel Secret)用雜湊加密後傳給玩家，待玩家下注後再將未加密的答案顯示給玩家，而玩家即可利用MD5加密驗證該字符串是否與下注前的加密字符串是否相相同

* **LINE 如何使用 HMAC**

client端需自行認證，從requset header 中拿到 X-Line-Signature
以及取得request的body，接著

    hash = hmac.new(channel_secret.encode('utf-8'),
           body.encode('utf-8'), hashlib.sha256).digest()

* **補充**

關於 Custom Header HTTP Header 使用 X- 前綴字來區隔 header 中的參數是標準參數或代表是 Custom 參數的參數，像這邊就是使用 X-Line-Signature，但於 [RFC 6648](https://tools.ietf.org/html/rfc6648) 中提到此方法已經不鼓勵 (discouraged) 使用 X-前綴字來命名。
不建議使用的原因為，將來會不易標準化header的參數
[來源](https://tonyxu.io/zh/posts/2018/http-deprecate-x-prefix/)

* **可能的漏洞**

若webhook網址被惡意使用者找到 且

1. 當Channel Secret外洩時
或
2. 當開發者沒有驗證X-signature

惡意使用者可任意組合message內容以及userId等，再自行加密X-signature以偽造此訊息的正確性，可能導致聊天機器人誤以為某使用者傳送了某訊息，進而執行更進一步的程式邏輯處理
詳見[**偽造user message**](https://trello.com/c/puKyifao/14-%E5%81%BD%E9%80%A0user-message)

* **預防**
1. 定期重新issue新的Channel Secret
2. 後端需驗證X-signature，確認每個message的來源正確性
3. webhook URL需保密

### [Facebook驗證機制](https://trello.com/c/RK5XscC5/8-facebook)

#### 訊息來源需自行轉寫程式判斷

程式自行判斷verify token與response body內的token相符

* **可能的漏洞**

1. 未撰寫驗證的程式碼
2. verify token外洩

=>偽造訊息

#### 傳送一般API的方法

curl -X POST -H "Content-Type: application/json" -d '{
  "messaging_type": "<MESSAGING_TYPE>",
  "recipient": {
    "id": "<PSID>"
  },
  "message": {
    "text": "hello, world!"
  }
}' "https://graph.facebook.com/v9.0/me/messages?access_token=<PAGE_ACCESS_TOKEN>"

### [Telegram驗證機制](https://trello.com/c/ulst1RlW/10-telegram)

https://core.telegram.org/bots/webhooks

1. telegram接收事件的方法有二
1. Long Polling
是指程式間隔一定時間透過 getUpdates取得訊息，缺點是浪費資源、不夠即時，所以適合在程式還沒有 deploy，在 develop 和 test 階段時使用。

2. webhook

2. **可能的漏洞**

* 沒有設定白名單ip

根據官方文件描述
> Accepts incoming POSTs from subnets
> 149.154.160.0/20 and 91.108.4.0/22
> on port 443, 80, 88, or 8443.

* token外洩

        606248605:AAGv_TOJdNNMc_v3toHK_X6M-dev_1tG-JA

### [What's App驗證機制](https://trello.com/c/6zNVVIDl/11-whatsapp)

https://developers.facebook.com/docs/whatsapp/guides/network-requirements

* **可能的漏洞**

1. 沒有設定白名單hostname
g.whatsapp.net
v.whatsapp.net
mmg.whatsapp.net
graph.facebook.com
static.whatsapp.net

2.token外洩

## 機密資訊外洩

如伺服器帳密，Token皆為 server重要的機密資訊

* 可能的外洩原因
1. 惡意套件
如NODE PACKAGE MANAGER可下載任意人上傳的套件，若有使用惡意第三方套件時，此套件可能可以讀取敏感資訊

2. 版本控制中包含機密檔案
如github上可掃描到有許多的專案把config setting env 等重要檔案同時上傳

3. 暴力破解取得Bot token
須封鎖多次的404惡意嘗試

## BOT SQL injection

* 在聊天框或輸入框內填寫送出，以竄改資料庫或取得機密資料等

  1' or '1' = '1' # 


## BOT Phishing

* **傳送假訊息** 或是 **Line Liff Xss**
聊天室給予惡意連結
如slack發生過的，發送一個權限認證的url，被惡意的連結應用程式取得權限

### slack實際案例
1. 從Github 中找到洩漏的webhook url
2. 建立一個惡意slack app，會跟使用者要求隱私權限
3. 利用洩露的webhook url傳送訊息 到例如#general頻道(slack可利用webhook URL 直接send message給頻道)
4. 釣魚訊息內容，如webhook設定須更新，以及惡意APP的隱私要求連結
5. 點擊後，惡意APP會得到此相關的隱私資料

## 若有將Bot SDK寫成API

例如將Line Push Message寫成一個http method
讓網頁端或是手機端管理後台，可以利用API操作傳送訊息的SDK
如此一來，不需要Token也可以透過沒有受到保護的API任意操作

所以，若有寫成API形式，需加上

1. 驗證機制
2. CSRF防範

## Line LIFF

### 何謂LIFF
Line Front-end Framework，簡稱Liff，是一個可以於聊天室視窗內呼叫一個前端網站並傳入此聊天室相關資訊的框架，例如聊天室ID、使用者名稱、傳送訊息等

### 風險
LIFF 由於為網站型態，故可能出現SQL injection以及XSS

* XSS
1. liff getProfile
使用者uid 名字 登入資訊洩漏
2. liff login
登入後執行惡意程式
3. liff shareTargetPicker
傳送竄改後的訊息

* SQL injection
詳見BOT SQL injection

## Bearer Token

* **定義**
[RFC 6750]https://tools.ietf.org/html/rfc6750)

Bearer Token 是由 Authorization Server 在 Resource Owner 的允許下核發給 Client ，Resource Server 只要認這個 Token 就可以認定 Client 已經經由 Resource Owner 的許可。

為了防範 Token 在傳輸的過程外洩，須使用 SSL/TLS 來防護，也因此 LINE 的 Webhook URL 僅能填入 HTTPS URL

* **LINE 如何使用Bearer Token**

發送 request 請求給 LINE Platform 時，於request header中Authorization欄位值為'Bearer ' + CHANNEL_ACCESS_TOKEN

* **可能的漏洞**
* Bearer token外洩

1. Line聊天機器人的所有API以及後台設定等皆運用Bearer token驗證，如傳送訊息或是修改webhook網址，將會導致此聊天機器人直接被惡意使用者控制

2. 若短暫的修改原始webhook URL，取得request header的X-signature後和request body後，馬上修改回來，再於本地端暴力破解可得到長度固定(32bit hex)的Channel Secret

         x-signature = HMAC(request body,channel secret

* **預防**

1. 定期重新issue Channel Access Token

## 總結
1. wehbook url 不可洩漏

不良的版本控制，以及未防止惡意掃描使容易猜測的網址洩漏

2. 需驗證訊息來源正確性

server端需驗證每次由機器人平台發出的事件來源是否正確，以避免第三方偽造訊息事件
user端對有疑慮的網址不得任意點擊或給予權限

3. 密碼與token需妥善儲存並定時更新

可能因不良的儲存方法或是惡意套件的竊取外洩密碼在不知情的時候，機器人平台皆有提供重新issue token的功能

4. 有使用到token的API需加上驗證機制

若token有保護好，但API的邏輯處理處理會運用到token時，此API必須透過驗證程序才得加以存取

5. 後端常見漏洞需多加注意
若有使用後台管理系統或是相關網站連結機器人資訊時，如SQL inject、CSRF、XSS等漏洞都是必須考量設計的

# 聊天機器人資訊安全-一般資料保護規範

## 1. 介紹
《一般資料保護規範》（General Data Protection Regulation，縮寫作 GDPR；歐盟法規編號：(EU) 2016/679[2]；通用資料保護規則）

## 2. 規範
處理個人資料的業務流程必須在設計和預設情況下構建資料保護，這意味著個人資料必須使用假名化或匿名化進行存儲，並且預設使用盡可能最高的隱私設置，以避免公開資料未經明確同意，並且不能用於識別沒有單獨存儲附加資訊的主題。