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. 金融機構資通安全防護基準 適用機構： 金融各類機構。 條文相關內容： 第四條、營運環境管理人員應符合下列要求： 五、除代登系統外於登入作業系統進行 系統異動或資料庫存取 時，應留存人為操作紀錄，並於使用後儘速變更密碼；但因故無法變更密碼者， 應建立監控機制，避免未授權變更，並於使用後覆核其操作紀錄。 八、加解密程式或具變更權限之公用程式（如資料庫工具程式）應列管並限制使用，防止未經授權存取並保留稽核軌跡。 九、 最高權限帳號使用時應先取得權責主管或授權人員同意並保留稽核軌跡 。 第五條、個人資料保護應符合下列要求： 五、應針對核心資通系統及各類電腦系統建置留存個人資料使用稽核軌跡（如登入帳號、...

前言 SSL / TLS ? 最近筆者剛轉職，正要進行第一個專案 👾 在某次 Sync 的會議中突然被問到： 舊版本的 SSL/TLS 為什麼危險，應該知道吧？  腦中突然浮現：「啊！之前在看 Microsoft 官方文檔確實有看到這塊，它建議升版 o.o」 好了，問題來了！ 那更深層次的問題，以及如何清楚解釋，我知道嗎？ 於是就有了這篇的誕生 ☺ 讓我們看下去吧！ 為什麼過去的 SSL/TLS 舊版協定比較危險？ 先聊聊什麼是 SSL/TLS SSL（Secure Sockets Layer）/  TLS（Transport Layer Security） 是一種用來 加密網路連線 的安全協定，用來確保你和網站之間傳輸的資料 不會被偷看、不會被竄改。 TLS 是 SSL 的後續版本，目前已發展到 TLS 1.3，具備更高的安全性與效能；舊版本如 SSL 3.0、TLS 1.0 和 1.1 已被淘汰，現代網站多採用 TLS 1.2 或 TLS 1.3 作為主流標準。 相關重點：SSL/TLS 握手（以 TLS 1.2 為例） 當 TLS 或 SSL 連線開始時，雙方會進行一個關鍵步驟叫做：「握手（Handshake）」。 這就像談戀愛前的「 確認彼此身分與溝通規則 」，要談情說愛之前，得先確定你是誰、我們怎麼講話、要不要加密、用哪種暗號（Cipher Suite）😇 握手的過程像是以下這樣： 關鍵澄清： 上方的圖片代表的是邏輯步驟，實際上這五個步驟不等於五個「RTT（Round Trip Time）」～ TLS 1.2 的實際 RTT 解釋如下：   在 TLS 1.2 中，完成一次完整握手大約需要「兩次往返（2-RTT）」的傳輸時間：  1. 第一個 RTT：  Client 發送 Client Hello（我支援這些 Cipher Suites）  Server 回應 Server Hello + 憑證 + Key Exchange + Hello Done  2. 第二個 RTT：  Client 發送 Client Key Exchange + Change Cipher Spec + Finished  Server 回應 Change Cipher Spec ...

前言 一個奇怪的夢境 說來也奇妙，今天夢到自己被飛船接走了 o.o 醒來後說不上來的精力充沛 @@ 直覺要我繼續去寫部落格跟學資安（？） 感謝 canva AI 產圖 最近我一直在探索自己的使命（?），同時也持續挑戰 OSCP Lab 👾 在閱讀「Common Web Attacks」的時候，無意間接觸到了「日誌中毒（Log Poisoning）」這個概念，讓我忍不住想更深入了解： 為什麼我們僅僅透過修改 HTTP Header，就可以污染伺服器的 log，甚至讓它被當成程式碼執行呢？  

資安標準:系統化地看待標準 😺何謂資安標準? 資安標準是為了確保資訊安全而制定的規範與準則，旨在降低網路攻擊風險、保護資料完整性、確保系統可用性，以及維護機密性。 常見的資安標準有很多，而這些標準通常由國際組織、政府機構或產業聯盟制定，以 指導企業、機構及個人如何有效實施資安措施 。 💜為什麼我們需要它? 這是一個相當有趣的問題，大家可以想想看已經紅了很久的議題: 數位轉型。 不知道讀者們有沒有想過: 當我們執行了數位轉型，會有什麼連帶的影響? 是變夯了? 變潮了? 還是資安威脅變多了 XD 數位轉型確實帶來了許多便利，但也讓網路威脅的攻擊面大幅擴張。企業需要確保新技術的安全性，而這正是資安標準存在的意義。 我們可以從以下的層面來看 ： 降低資安風險 ：透過標準化的安全控制措施，減少攻擊面。 符合法規要求 ：許多國家與產業要求遵守特定資安標準，如 GDPR（歐盟一般資料保護規範）。 提升信任度 ：遵循標準可向客戶、合作夥伴及投資者展示資訊安全能力。 簡化安全管理 ：標準提供明確的指南，使組織能夠系統化管理資安。 👾常見資安框架/標準 筆者在此介紹一個標準 & 一個框架來讓讀者有個初步的認識 ~ ISO 27001（資訊安全管理標準，ISMS） 簡單來說 ： 這是一個國際標準，指導企業如何建立 資訊安全管理機制 ，確保資料不外流、不被攻擊或意外遺失。 它的核心是 風險管理 ，強調 先找出可能的安全問題，然後降低風險 。 適用於任何組織，無論是企業、政府機構，甚至學校，都可以用來強化資安。 重點 ✔️ 風險評估 ：識別組織內的資安風險，例如：資料外洩、駭客攻擊。 ✔️ 安全控制 ：建立標準流程來防範這些風險，例如：存取權限管理、定期審查、備份機制。 ✔️ 持續改善 ：透過內部稽核與資安評估，確保企業安全機制符合標準。 簡單理解 ： ISO 27001 就像是一套 公司資安管理規則 ，確保企業內部對資訊安全有一套明確的方法來執行與監控，而不只是隨機處理資安事件。 不同版本的 ISO 27001 ： 演進與變化  💫 ISO 27001:2013（舊版）  包含 114 項控制措施，分為 14 個領域（如存取控制、密碼管理、營運安全等）。  著重於風險管理，確保企業識別、評估和降低資訊安全風險。 適用於各類型組織，但當時的技術環...

何謂零信任? 「零信任」是一種網路安全模型，它的核心概念就是「內外皆不可信」。它的核心原則如下： 1. 持續監控與驗證： 「驗證使用者與裝置的身份與安全性」，並在登入與連線後設置超時機制，強制使用者與裝置定期重新驗證，確保持續安全。 2. 最小權限原則： 網路「僅授予使用者與裝置必要的存取權限」，並逐一驗證連線，定期重新驗證，以嚴格控管內部潛在威脅。 3. 微分段： 「將網絡劃分為小型安全區域」，各區域獨立管控存取權限。即使獲得其中一個區域的授權，未經額外許可，仍無法存取其他區域，從而強化安全性。 👀 可能產生誤解的概念說明： 微分段不等於子網劃分 ，所謂的「子網」（Subnet）是傳統網絡架構的一部分，透過劃分 IP 位址範圍 來組織設備。 然而，「微分段」則有所不同，它比子網劃分更進一步， 即使在相同的子網內，存取仍需要個別授權。 4. 防止橫向移動： 存取採用分段控制，並需定期重新驗證，使攻擊者無法在網絡中橫向移動。一旦偵測異常，系統可隔離受感染裝置或帳戶，立即阻斷進一步存取，防止攻擊擴散。 5. MFA（多因子身份驗證）： 使用多個證據證明使用者身份，如：密碼、裝置代碼等。 6. 裝置存取控制：  「嚴格控管裝置存取」，要求監控所有試圖連接的裝置，確保它們經過授權，並評估其安全性，以防遭受入侵。 以上是零信任常見的幾點原則，基本上就是圍繞著裝置、身份驗證、切割管理區域、權限控管等。 備註：筆者也有把上述的文字整理成心智圖，方便大家增強記憶～有興趣可以點擊圖片存取 💪 💘 零信任帶來的價值與影響 在傳統網絡安全架構中，系統通常預設內部網絡是「安全的」，只需在邊界（如 VPN、防火牆）設置防護。但隨著 遠端辦公普及、雲端應用激增、網絡攻擊越來越精細 ，這種方式已經不夠安全。 前面我們已經介紹過 零信任的原則 ，總結來說， 零信任（Zero Trust） 的核心概念其實很簡單，主要包括： 1. 沒有人或裝置是天生可信的，每次存取都需要驗證。  就像人與人交流時，即使是親朋好友講的話也不一定完全可信，需要自己判斷（看看最近的心靈課程事件就知道了 XDD）。  2. 確保每個人與每台設備只能存取他們應該存取的資源，沒有例外。  這意味著即使是內部員工或受信任設備，也無法隨意存取無關的系統與數據，從而減少潛在風險。 在了解...