Secured by Kika (=ˆ꒳ˆ=)

前言 最近筆者忙著衝刺 OSCP Lab，過程中發現了一個有趣的小東西： PHP Wrapper 。 其中有個特別讓人眼睛一亮的東東： data:// 。 那時候我心裡想， data://  ... 怎麼長得跟之前看到的 「 瀏覽器支援的 內嵌資源格式 」 ：「 data: 」 有 87% 相似？ 結果這個念頭就剛好戳中我的強迫症，忍不住想把兩者 好好整理、比較一下 。 👾 PHP wrapper 的 data:// 危險在哪？ 什麼是 PHP 的 data:// 它是  PHP 官方提供的「虛擬檔案協定」 。  讓你可以用「字串」來模擬成一個「檔案」給 PHP 讀取。   會被  include() 、 file_get_contents() 、 fopen()  等函數當成檔案來處理 。 為什麼危險？ 本來 PHP 讀的是「伺服器上的檔案」。 攻擊者卻可以透過 LFI 等漏洞，把 data:// 這種「假的檔案」塞進去。 最後讓 PHP 讀取、甚至「執行」這些字串內容。 舉例來說： include('data://text/plain;base64,PD9waHAgZXZhbCgnY2F0IC9ldGMvcGFzc3dkJyk7ID8+'); 這行會讓 PHP 執行這段 base64 編碼過的惡意 PHP 程式碼 。 本質上的風險：   原本應該只能從硬碟讀的檔案，卻被攻擊者用 data:// 偷渡進來。  不用上傳檔案、不用寫入磁碟，光靠一段字串，就能讓伺服器乖乖幫忙執行惡意程式碼。 💣 Client 端的 data: URL 危險在哪？ 什麼是 Client 的 data: URL   是瀏覽器支援的 內嵌資源格式 。  可以用來嵌入圖片、HTML、PDF、CSS 等等。 常見例子： < img src = "data:image/png;base64,...." /> 為什麼危險？ 1. 攻擊者可以把惡意內容藏在 data: URL 裡面 。 例如： data:text/html;base64,xxxx -> 直接夾帶 XSS 攻擊內容。 data:application/octet-stream;base64,xxxx -...

Log ，我到底要記錄什麼？ 前言 最近筆者開始要準備上工，無意間接觸到「Log 記錄」的議題，於是開始著手研究它。 自從開始擔任顧問後，我的視角從單純的開發者，逐漸拓展至企業層面與內部人員的需求。 現在的我開始嘗試從「合規」與「導入實務」的角度切入，並歸納出一套可供初步參考的思維架構，針對不同企業規模與需求，逐步拆解背後的問題邏輯。 捫心自問時間 在正式進入「優化你我的 Log」之前，先來個捫心自問的時刻： 你的系統， 有明確的合規要求 嗎？ 還是你只是 希望讓 Log 記錄更清晰、好用、有效 ？😉 這兩種出發點，會直接影響你後續的 Log 設計邏輯與優先順序： 合規導向 的 Log，通常是為了滿足法規、稽核標準與保留期限的要求。這類設計需要強調操作可追溯性、角色辨識與完整性。 優化導向 的 Log，則更著重於開發與維運需求，包括除錯便利性、使用行為分析、效能監控，甚至 強化異常偵測與安全預警 的能力。 釐清需求，是打造良好 Log 記錄策略的第一步，也是你省下大量重構成本的起點。 法規 Review 接下來，我們就先針對「法規」的部分，先做進一步地釐清。 根據不同產業別，需要做的事情也會不同，筆者列出幾個跟「Log」有一些關聯的法規。 常見法規與內容說明 1. ISO 27001:2022  適用機構： 希望建立資訊安全管理系統（ISMS）並取得 ISO 國際認證的各類組織（如政府機構、金融業、科技業、醫療單位、雲端服務商等）。 條文相關內容： 8.15 存錄 紀錄活動、異常、錯誤及其他相關事件之日誌，應產生、儲存、保護及分析之。 2. 金融機構資通安全防護基準 適用機構： 金融各類機構。 條文相關內容： 第四條、營運環境管理人員應符合下列要求： 五、除代登系統外於登入作業系統進行 系統異動或資料庫存取 時，應留存人為操作紀錄，並於使用後儘速變更密碼；但因故無法變更密碼者， 應建立監控機制，避免未授權變更，並於使用後覆核其操作紀錄。 八、加解密程式或具變更權限之公用程式（如資料庫工具程式）應列管並限制使用，防止未經授權存取並保留稽核軌跡。 九、 最高權限帳號使用時應先取得權責主管或授權人員同意並保留稽核軌跡 。 第五條、個人資料保護應符合下列要求： 五、應針對核心資通系統及各類電腦系統建置留存個人資料使用稽核軌跡（如登入帳號、...