別再讓你的網站裸奔了！Cloudflare 讓你 5 分鐘變身網路防護高手
半夜接到電話說網站掛了的感覺，過一次就不想再有第二次。Cloudflare 不是什麼魔法，但它確實解決了大部分小網站會遇到的問題：DDoS、SSL 憑證、DNS 緩慢、靜態資源重複傳輸。 什麼是 Cloudflare？它站在你和流量之間Cloudflare 是一個反向代理網路，全球超過 330 個資料中心，當使用者連到你的網域時，流量先經過 Cloudflare 的節點，再轉發到你的伺服器。這個架構帶來三件事： 流量過濾：惡意請求在邊緣節點就被攔下，DDoS 流量能降低到達源站的機率，但沒有任何系統能保證攔下所有入侵手法。 靜態快取：HTML、CSS、圖片等靜態資源就近回應，不必每次打到源站。 邊緣 SSL：訪客到 Cloudflare 邊緣的連線自動加密，但端到端安全還取決於你選擇的 SSL/TLS 模式與源站憑證狀態（後面細說）。 根據 Cloudflare 2025 年第一季報告，Q1 阻擋了 2,050 萬次 DDoS 攻擊，較去年同期增長 358%。目前他們的網路容量已達 500 Tbps，是 2025 年底有紀錄以來最大攻擊（31.4 Tbps）的約 16 倍。 ...
IIS 網站被植入惡意轉址：用 Google Search Console 驗證擁有權與清查後門
先搞清楚：你遇到的多半不是「DNS 污染」訪客連到你的站，結果被導去陌生的廣告頁；Google 搜尋結果裡你的網頁掛著一堆藥品或博弈關鍵字；你打開首頁原始碼，發現 <head> 多了一段看不懂的 <script>。第一個冒出來的念頭通常是「我被 DNS 污染了」。 但這兩件事發生的地方完全不同，搞錯方向會白忙一場。 DNS 快取污染（DNS cache poisoning / spoofing）發生在 DNS 解析器，不在你的伺服器上。 攻擊者往遞迴解析器塞假的解析結果，讓所有用到那台解析器的人把你的網域解析到攻擊者的 IP。受害的是解析層，動到的是別人家的快取，你改自己網站的 web.config、清 wwwroot、封鎖 .php，一點用都沒有，因為惡意內容根本不是從你的主機送出去的。這類攻擊通常範圍很大（一台 ISP 解析器可能服務上百萬人），而且你在自己機器上 nslookup 出來的 A 記錄往往是正常的。 如果出現的症狀是「首頁原始碼被塞了東西」「wwwroot 多出沒見過的 .php / .aspx 檔」「IIS 記錄檔有可疑的 POST」，...
SQL Server資料庫加密實戰:透明資料加密(TDE)完整實作指南
前言資料庫檔案外洩的成本往往不在攻擊當下，而在事後。SQL Server 的透明資料加密（Transparent Data Encryption，TDE）能在資料寫入磁碟時自動加密、讀取時自動解密，對應用程式完全透明，不需改一行程式碼。本文從建立主金鑰到啟用加密逐步實作，並說明實務上需要注意的地方。 TDE運作原理TDE 保護的是磁碟上的靜態資料，也就是 .mdf、.ldf 等資料庫檔案本身。寫入磁碟時加密、從磁碟讀取時解密，整個流程發生在資料庫引擎層，應用程式完全不感知。 金鑰階層如下： 資料庫檔案 資料庫引擎 記憶體 資料庫加密金鑰 憑證 加密 解密 TDE優缺點分析優點 對應用程式透明，不需修改程式碼 保護整個資料庫檔案，包含交易日誌 ...
別急著關掉 TLS 1.2：升級 TLS 1.3 前該懂的 Windows 相容性真相
資安弱掃跑完，報告上一條紅字：偵測到過時的 SSL/TLS 協定。很多人看到就把 TLS 1.0、1.1、1.2 全關掉，只留 TLS 1.3——想說版本越新越安全。 問題就出在這：弱掃從來沒叫你關 TLS 1.2。把 1.2 一起關掉、只留 1.3，在 Windows 伺服器環境幾乎一定出事——網站連不上、SQL Server 連不上、舊的內部系統全掛。下面拆解為什麼，以及正確的做法。 先搞清楚：弱掃到底要你關什麼弱掃報告寫「過時的 SSL/TLS 協定」，指的幾乎都是 SSL 2.0/3.0 和 TLS 1.0、1.1。這幾個有已知的結構性弱點（POODLE、BEAST 那一掛），該關。 TLS 1.2 不在這個清單裡。它到現在仍然安全、主流、被廣泛支援。常見的合規型弱掃通常不會要你停用 TLS 1.2。 法規這邊也說得很清楚。PCI DSS 4.0 的要求是「TLS 1.2 或更高」，把 SSL 和 early TLS（1.0/1.1）列為不合規。它從來沒要求你用 TLS 1.3——TLS 1.2 完全合規。所以「只留 TLS 1.3」這種建議，不是弱掃的要求，是誤讀。 為...
IISCrypto - 資安弱掃的救星！一鍵搞定 TLS 設定
前言做資安弱點掃描，最常踩到的地雷之一就是 SSL/TLS 設定。掃描報告跳出一堆「Server supports TLS 1.0」、「Weak cipher suite detected」，修法不外乎就是去翻 Windows 登錄檔——路徑又長，改錯一個值可能把整台伺服器的 HTTPS 搞壞。 IISCrypto 是 Nartac Software 做的免費工具，把這些作業全包進圖形介面，幾分鐘內就能把 TLS 設定從滿江紅改成合規狀態。 什麼是 IISCrypto？IISCrypto 是 Windows 伺服器上的 SSL/TLS 設定管理工具。它底層還是在改 Windows 登錄檔，但省掉你自己找路徑、手動調值的過程。主要能操控三件事：啟用或停用哪些加密協定、調整加密套件（cipher suite）的優先順序、設定簽章演算法的選項。 系統需求：Windows Server 2012 或以上、本機管理員權限、.NET Framework 4.6.2 或以上。 為什麼用它？PCI DSS 合規需求PCI DSS v4.0 要求停用 SSL 和 early TLS（也就是 TLS...
IIS 網站突然狂丟403錯誤！原來是安全性設定在搞鬼
前言某一天，系統突然開始出現詭異的現象：使用者回報網站時好時壞，重新整理一次可能好，但下一秒又壞了。查看記錄檔發現大量的 403 Forbidden 錯誤，但最讓人困惑的是，同一個檔案，有時候能載入，有時候卻被封鎖。這到底是怎麼回事？ 1. 檔案/資料夾權限設定問題先從最常見的原因開始排查： 確認網站資料夾的 NTFS 權限是否正確 IIS_IUSRS 和 IUSR 使用者需要有讀取權限 Application Pool 身份對網站目錄需要有讀取權限 2. IIS 設定檢查 在 IIS 管理員中確認網站的身份驗證設定 檢查是否啟用了正確的驗證方式（如匿名驗證） 確認網站綁定設定是否正確 以上全部確認過，都沒有問題，403 依然持續出現。 問題的關鍵：動態 IP 限制設定以上都查過沒問題之後，只能在網站上重複重新整理，同時盯著 IIS 記錄檔看。記錄檔裡確實有很多 403，但看不出理由。接著注意到一件事：原本 403 的檔案忽然正常了，反而其他檔案變成 403。多重整幾次，每次被影響的檔案都不一樣。 到這裡方向就清楚了。這不是靜態的權限問題，而是動態封鎖——問題的源頭是 II...
在 .NET Core + Vue.js 專案中實作 CSRF 防護
安全性掃描丟回來一張紅單那次例行安全性掃描跑完，報告裡躺著一條 CSRF（Cross-Site Request Forgery）漏洞。專案是前後端分離：後端 .NET Core Web API，前端 Vue.js 跑在另一個來源（origin），用 Cookie 帶身分驗證。這種架構最容易踩到 CSRF，因為瀏覽器只要看到對應網域，就會自動把 Cookie 附上去，不管請求是誰發起的。 補這個洞花的時間比我預期久，主要卡在兩個地方：一是 ASP.NET Core 的 Antiforgery API 有不少網路文章寫錯，照抄根本編不過；二是 SameSite 設定跟前後端分離的架構互相打架，調了好幾次才搞懂。這篇把走過的彎路記下來，程式碼都實際跑過。 CSRF 到底在攻擊什麼CSRF 利用的是「瀏覽器會自動帶 Cookie」這件事。攻擊不需要偷到你的帳密，它借用的是你「已經登入」的狀態。 典型流程是這樣： 使用者登入了網路銀行，瀏覽器存了驗證 Cookie 同個瀏覽器分頁打開了一個惡意網站 惡意網站偷偷送一個 POST 到網路銀行的轉帳端點 瀏覽器看到目標是網路銀行，就把驗證 C...
Content Security Policy 設定指南：nonce 才是正解，unsafe-inline 是最後手段
CSP 擋 XSS，靠的是禁止執行 inline script先把一件事講清楚，後面整篇都建立在這上面：Content Security Policy 能擋跨站腳本（XSS），核心機制就是禁止頁面執行行內（inline）的 script。 攻擊者注入 XSS 時，塞進 DOM 的往往是 <script>alert(document.cookie)</script> 這種直接寫在 HTML 裡的程式碼，或是 onclick="..." 這類行內事件處理器。瀏覽器一旦套上嚴格的 script-src，這些東西就跑不起來——這才是 CSP 的價值所在。 所以當你在 script-src 加上 'unsafe-inline'，等於告訴瀏覽器「行內 script 全部放行」。攻擊者注入的那段也一起放行了。這時候 CSP 對 XSS 的防護等於拆掉，剩下的 default-src 'self'、白名單域名都救不回來。 配置 CSP 的目標因此很單純：讓網站不靠 'unsafe-inline' 也能正常...
防駭客必學！一次搞懂 IIS HSTS 設定，告別 HTTPS 降級攻擊
你的網站已經設定 HTTPS 了嗎？光設定 HTTPS 還不夠——本文拆解 HSTS 的運作原理，並示範在 IIS 上的兩種設定方式。 問題發現：弱點掃描警告最近在進行專案的弱點掃描時，發現了一個低風險的問題： 弱點說明提到：應用程式未設定 HTTP Strict Transport Security (HSTS) 標頭。這可能讓攻擊者有機會進行 HTTPS 降級攻擊，竊取敏感資訊。 什麼是 HSTS？為什麼這麼重要？HSTS 全名是 HTTP Strict Transport Security，定義於 RFC 6797，是一個 HTTP 擴充標準。它的主要功能是： 強制瀏覽器使用 HTTPS 與網站進行通訊 有效防禦 SSL 剝離攻擊 保護使用者的敏感資訊 避免憑證警告被忽略 HSTS 運作原理讓我們看看 HSTS 是如何運作的： 使用者第一次存取網站 伺服器在回應中加入 HSTS 標頭 瀏覽器記住這個安全設定 之後瀏覽器在發出請求前，會於本機直接將 HTTP 升級為 HTTPS（307 Internal Redirect），不會先送出不安全的請求 有效防止中間人攻擊 ...
IIS中COOKIE的安全設置
本文介紹 IIS（Internet Information Services）中兩個關鍵的 Cookie 安全設定：httpOnlyCookies 和 requireSSL，說明各自的作用與 web.config 寫法。 問題背景最近，專案在進行弱點掃描時發現了一個與 ASP.NET_SessionId 有關的弱點。掃描結果顯示，這個重要的 Session ID 缺少必要的安全 Flag。因此，我決定仔細研究 IIS 中 Cookie 的安全設定，特別是 httpOnlyCookies 和 requireSSL 這兩個選項。 httpOnlyCookies什麼是 httpOnlyCookies?httpOnlyCookies 是一個安全特性，用於防止客戶端腳本存取受保護的 cookie。當啟用此選項時，cookie 只能透過 HTTP(S) 協議傳輸，而不能被客戶端腳本（如 JavaScript）存取。 為什麼重要?啟用 httpOnlyCookies 可以顯著降低跨站腳本（XSS）攻擊的風險。攻擊者即使成功注入惡意腳本，也無法直接讀取或操作受保護的 cookie，從而保護了敏感...
