misconfiguration
该标签下有 10 篇文章
云存储被公开暴露：即使开启了「阻止公有访问」，数据也可能泄露
存储桶泄露来自配置，而不是攻击。文档里最关键的一句是：阻止公有访问的设置不会修改现有的策略或 ACL——公开设置留在阻止层下面，一旦解除阻止，公开访问就会恢复。所以目标不是「已开启阻止」，而是「关掉阻止也没有任何东西是公开的」。要在账户级别启用，因为存储桶策略可以授予别人关闭存储桶级阻止的权限。而且「公开」的定义比大多数人想象的更宽。
4 种常见的安全错误：默认设置、遗忘的服务、缺少监控、过度信任输入校验
事故来自少数几种反复出现的模式，而按想法归类比按技术归类更清楚。四种想法是：默认值应该是安全的（什么都没设置）、不用的东西应该无害（什么都没关闭）、出事了我们会发现（什么都观察不到）、校验过的输入应该是安全的（交给输入决定的东西太多）。修正它们都不需要深入的技术知识——需要的是检查的习惯。下面分别说明每一种该看什么。
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) 自查清单。仅防御，不含攻击步骤。
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) 自查清单。仅讲防御，不含攻击步骤。
是否把密钥文件遗忘在了公开目录里：webroot 盘点
放进 webroot 的文件，任何人都能通过 URL 取走。令牌或认证凭据的 JSON、.env、备份一旦遗忘在那里，就会立即暴露；如果源自共用模板，所有站点都带着同一个文件。对策：公开目录只放可以公开的东西，密钥放在 webroot 之外并设为权限 600，一旦发现一处，就排查所有站点和主机。
X-Forwarded-For（XFF）伪造是什么：信任代理的配置错误与防御
XFF 是客户端可以伪造的头。在伪造 XFF 里放入注入探测的无差别扫描是典型手法，而『信任全部代理（通配符）』的配置会让它通过。短期处理＝在边界对 IP 头做净化，根本对策＝只信任合适的代理（或一个都不信任）。即便没有实际损害，也有该修复的配置。
Laravel 的 .env 可被公开读取的案例：共享虚拟主机上的部署位置错误与修复方法
根本原因是『把应用本体放到了 public_html 目录正下方』。本该只暴露 public/。按临时用 .htaccess 拦截→密钥轮换→结构改造三个阶段修复，并用机制防止再次发生。