當心營運資訊裸奔-網站偵錯 Log 檔常犯的資安錯誤

「寫 Log」是很有效的線上系統偵錯手段,就像飛機黑盒子或行車記錄器,能在事故發生後提供寶貴資訊,釐清肇事原因,還能用於責任歸屬舉證。例如:

  1. 系統不定期爆炸,由 Log 歸納每次發生在某使用者進行某項操作之後
  2. 客戶否認下單,調閱 Log 舉證登入時間,來源 IP 以及操作順序,萬一客訴鬧上法院還可當作呈堂證供
  3. 資料庫發生 Deadlock,由 Log 找出事件當下兩名使用者執行的作業及輸入參數,鎖定可疑 SQL 語法進行調查

簡單來說,愈重要的網站系統愈需要 Log 機制協助維運,而 Log 該保存什麼內容,視作業性質而定,不外乎時間、IP 來源、使用者身分、操作參數… 等。而Log 儲放位置有很多選擇,本機檔案、Log 資料庫、Log 伺服器… 等。其中以本機檔案執行成本低、速度快,不易故障,可靠性最高,是最常見的 Log 選項。


Image by thom

由於 Log 會內含機敏資訊,若是處理不慎,Log 檔可能成為營運機密或個資洩漏的源頭。前陣子剛好看到營運資料透過 Log 檔在網站裸奔的案例,猜想有些開發朋友還沒意識到這類潛在風險。本文將整理我所想到處理網站 Log 常犯的錯誤及其可能衍生的資安風險:

未排除個資或機密資訊

以事後偵察的角度,保留資訊愈完整,愈能還原現場,故開發人員有時會將所有輸入參數與輸出結果都留在 Log 裡,但這裡有個常犯錯誤,機密敏感資料例如:身分證號、密碼、銀行帳號、信用卡號、地址、電話… 等也被寫入 Log,而系統管理者處理 Log 檔的資安敏感度不如原始碼、資料庫嚴謹,導致 Log 檔案外流的機率較其餘二者為高,一旦 Log 檔落入賊人之手,其中的個資會惹來無窮麻煩。

解決之道在於調整程式邏輯,排除個資或機密資料,若必須保留也請打上馬賽克,例如:身分證號寫成 A12XXXXX89,密碼只留頭尾一碼(甚至全部遮罩),電話號碼改成 0937XXX123,信用卡號改成 1234-XXXX-XXXX-5678。不保留完整內容,在某些情境會影響還原現場的完整度,但必須取捨,依實務經驗,即使參數被馬賽克,仍可從相關資訊識別請求來源,應付大部分偵錯需求綽綽有餘。衡量其風險及必需性,針對機密或個資,強烈建議排除或馬賽克處理。

將 Log 檔直接放在網站目錄下

有些開發者選擇在網站資料夾下開個 Log 之類子錄(例如:wwwroot\MyApp\Log)放記錄檔。將存取 Log 跟網站放在一起,相關資訊集中管理貌似天經地義,但要當心一個天大陷阱: 一旦 Log 路徑及檔名被惡意人士掌握,對方開個瀏覽器輸入 URL 就能光明正大將 Log 下載回去把玩,要是 Log 還包含個資、帳號密碼、交易內容... 事情就大條了。說不定接著會上演「黑先生,您最近有在我們網站買了一本單元測試的藝術 [第二版],因系統問題被設成 12 期分期每月扣款,需要您到 ATM 機器解除設定...」

因此,除了個資及敏感內容要馬賽克,也請不要將 Log 放在可直接下載的資料夾範圍。一般來說,外界很難得知 Log 路徑檔名,但無法排除以下狀況:

  1. 取得原始碼或網站檔案備份
  2. 由其他網站或測試台觀察到目錄結構
  3. 使用讀心術、通靈術瞎猜矇到

一旦路徑被掌握加上 Log 附檔名是網站允許的 MIME 型別(例如: .txt),後果會十分慘烈,不可不慎。如果一定要集中放在網站目錄,請設定排除規則禁止外部透過 GET/POST 該路徑下的內容,或是善用 ASP.NET 的 App_Data 隱身特性,但強烈建議在網站目錄之外為 Log 另開專屬目錄存放更安全。

備份與複製檔案時未排除 Log

在實務上,基於管理、偵錯需求有時我們需要備份或複製整個網站或整台主機檔案,對於程式檔案管理者的警覺性不像對待資料庫或資料檔那麼高規格,加上沒有意識到包含商業機密的 Log 檔案也在其中,備份檔可能被放在不夠安全地方且未嚴格限定存取,導致 Log 內容外流。

依我的經驗 ,備份或複製網站程式檔較常發生(換版前備份、複製到其他主機重現問題),將 Log 移出網站資料夾,除非備份整顆硬碟或刻意選取 Log 資料夾執行,Log 被意外備份或複製的機率可大幅下降。這也是我強烈建議另外為 Log 建立專屬資料夾的理由,除了避免不小心被備份或複製,管理者操作時能更明確認知到他在處理包含營運資訊的內容(前題是要有 Log 會內含機密資訊的認知),而不是當成程式有所輕忽。

非必要的偵錯詳細資訊

這個是較罕見的低級錯誤,我曾見過開發者為了偵錯時能萬無一失,居然在 Log 檔中印出資料庫連線字串備查。(我的老天鵝)
敢這麼做多半基於一個假設: Log 檔永遠被會嚴加保管,限制管理者存取。理應如此,但你知道的,實務上總會有豬隊友,有意外。面對資安議題,永遠假設機制會失靈,人為必有疏失就對了。決定要在 Log 寫入機密資料前,若評估一旦外洩會有嚴重後果,除非有絕對理由必須承擔此風險,否則別這麼做。

 

最後總結處理網站 Log 的幾點資安原則:

  1. 排除機密敏感內容,若必須保留要加馬賽克
  2. 避免允許使用者透過網站直接下載 Log 檔
  3. 為 Log 另建專屬資料夾避免因備份或複製而外流
  4. 開發者及系統管理者應建立 Log 可能內含機密資訊的認知
  5. 永遠假設 Log 可能外流,避免寫入非必要的機密資訊
歡迎推文分享:
Published 04 October 2017 11:25 AM 由 Jeffrey
Filed under:
Views: 9,019



意見

# 毛豆 said on 04 October, 2017 05:23 AM

發現了置入性行銷   XD

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<October 2017>
SunMonTueWedThuFriSat
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234
 
RSS
創用 CC 授權條款
【廣告】
twMVC
最新回應

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication