misconfiguration
該標籤下有 8 篇文章
Django 的資安對策 — 正式環境強化實務參考
Django 是「電池全含」帶有安全的預設（ORM、CSRF、自動轉義、認證），但事故來自設定。本頁是可實作的參考：(1) 依優先度排序的強化清單（P0–P2）(2) 各領域指引——DEBUG=False＋ALLOWED_HOSTS、把 SECRET_KEY 外部化、pip 相依套件 CVE、正式環境安全設定（SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE 等）、授權（擁有者範圍）、注入與輸出（raw/extra、mark_safe/|safe）、CSRF/工作階段/admin、SSRF/上傳，以及 (3) 自我檢查清單。純防禦——不含攻擊步驟。
各框架的資安對策 — 依你所用技術量身打造的防禦方式
無論你用哪個框架，攻擊者鎖定的弱點『類型』大致相同（存取控制、機密資訊、注入、相依套件 CVE、設定錯誤）。不同的是各框架的『危險預設值』與『最常被鎖定的位置』。本站為每個框架備妥『預設陷阱』與『加固步驟』。先從你實際使用的框架章節讀起。
Laravel 資安對策 — 正式環境的加固參考
Laravel 的預設值很強；正式環境的事故來自設定與維運。這是一份可實作的參考：(1) 依優先度排序的加固檢查清單（P0–P2）、(2) 一張危險預設值的表格、(3) 各領域指引——機密／APP_KEY、正式環境設定（APP_DEBUG／快取）、授權（Policy/Gate、Mass Assignment）、注入／輸出（Eloquent 綁定、Blade）、工作階段／CSRF／cookie、上傳、HTTPS／標頭／限流、Composer 相依套件 CVE，以及 (4) 自我驗證檢查清單。純防禦——不含攻擊步驟。
Spring Boot 的資安對策 — 正式環境強化實務參考
Spring Boot 是穩固的地基，但事故來自相依套件、設定與授權。本頁是實務參考：(1)附優先度的強化檢查表(P0〜P2) (2)分領域的具體對策＝相依套件 CVE(Log4Shell 系、以實際執行版本判定)、正式環境設定與機密的外部化、Spring Security 的授權(預設拒絕/方法授權/擁有者檢查)、Actuator/管理面的暴露削減、不安全的還原序列化、注入、標頭/CSRF/工作階段、SSRF (3)自我檢驗檢查。只談防禦與點檢，不含攻擊步驟。
ASP.NET Core 的資安對策 — 正式環境強化實務參考
ASP.NET Core 是成熟穩固的地基，但事故來自設定。本頁是可實作的參考：(1) 依優先度排序的強化清單（P0–P2）(2) 各領域指引——正式環境不外露詳細錯誤／開發者例外頁面、把秘密外部化（User Secrets/環境/Key Vault）、NuGet 相依套件 CVE、授權（[Authorize]、fallback 預設拒絕、資源型/擁有者）、過度接收（DTO/[Bind]）、不安全的還原序列化（避免 BinaryFormatter）、HTTPS/標頭/antiforgery、SSRF，以及 (3) 自我檢查清單。純防禦——不含攻擊步驟。
是否把金鑰檔案遺忘在了公開目錄裡：webroot 盤點
放進 webroot（公開目錄）的檔案，只要存取 URL 任何人都能取走。權杖或驗證憑證的 JSON、.env、備份一旦遺忘在那裡，立刻造成實害。再加上若源自共用範本，同一個洞會橫向擴散到所有站點。對策＝公開目錄只放可以公開的東西，金鑰放在 webroot 之外＋權限 600，並且盤點自己的伺服器、一處發現就全機排查。
X-Forwarded-For（XFF）偽造是什麼 — 信任代理設定的陷阱與防禦
XFF 是用戶端可以偽造的標頭。在偽造 XFF 裡夾帶注入探測的無差別掃描是典型手法，而『信任全部代理（萬用字元）』很危險。對症處理＝對 IP 標頭做淨化，根本＝把信任代理收斂到合適範圍。即便沒有實際損害，也有該修復的設定。
Laravel 應用程式的 .env 被暴露給全世界——共享虛擬主機上最常見的部署錯誤
根本原因是『把應用程式本體放到了 public_html 目錄正下方』。本該只暴露 public/。按緊急處置→金鑰輪換→結構改造三個階段修復，並用機制防止再次發生。