misconfiguration
该标签下有 8 篇文章
Django 安全 — 生产环境加固实务参考
Django 主打“开箱即用”，自带安全默认值（ORM、CSRF、自动转义、auth），但事故来自配置。这是一份实务参考：(1) 优先级排序的加固清单（P0–P2）；(2) 分领域指引——DEBUG=False + ALLOWED_HOSTS、把 SECRET_KEY 外置、pip 依赖 CVE、生产环境安全配置（SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE 等）、授权（所有者范围）、注入与输出（raw/extra、mark_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) 分领域指引——生产环境不暴露详细错误 / Developer Exception Page、把密钥外置（User Secrets/环境变量/Key Vault）、NuGet 依赖 CVE、授权（[Authorize]、回退默认拒绝、基于资源/所有者）、over-posting（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/。按应急处置→密钥轮换→结构改造三个阶段修复，并用机制防止再次发生。