access control
该标签下有 10 篇文章
OWASP Top 10 是什么 — Web 应用十大安全风险的权威清单
OWASP Top 10 是非营利组织 OWASP 每隔数年发布一次的『Web 应用十大最严重风险』清单，被广泛用作开发者与运营者的共同语言。最新版（2021）以『访问控制缺陷（Broken Access Control）』居首，随后是注入、配置错误、脆弱且过时的组件、认证缺陷等。它们是风险的『类别』而非单个攻击手法，正确用法是把它当作审视自己应用的观点。
PCI DSS 是什么 — 处理信用卡数据所需遵守的安全标准
PCI DSS（Payment Card Industry Data Security Standard）是存储、处理或传输卡数据的商户需要满足的国际安全标准，由各卡组织制定，要求网络保护、存储数据加密、最小权限访问控制、监控/日志、脆弱性管理等。实务中最安全的做法是：干脆不要自己持有卡号，把卡处理交给合规的支付服务商（令牌化），从而把适用范围缩到最小。
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) 自查清单。仅防御，不含攻击步骤。
Laravel 安全 — 生产环境加固参考手册
Laravel 的默认值相当扎实；生产环境的事故来自配置与运营。这是一份可直接照做的参考：(1) 按优先级排序的加固清单（P0–P2），(2) 一张危险默认设置的表格，(3) 分领域指南——密钥/APP_KEY、生产配置（APP_DEBUG/缓存）、授权（Policy/Gate、Mass Assignment）、注入/输出（Eloquent 绑定、Blade）、会话/CSRF/Cookie、上传、HTTPS/响应头/限流、Composer 依赖 CVE，以及 (4) 一份自查清单。纯防御——不含攻击步骤。
Next.js 安全 — 生产环境加固实务参考
Next.js 的默认配置相当安全，但事故发生在服务端/客户端的边界上。本页是一份可上手的实务参考：(1) 按优先级排序的加固检查清单（P0–P2）；(2) 分领域指南——边界与环境变量（NEXT_PUBLIC_）、依赖 CVE（含核心 RCE）、Server Actions / Route Handlers 的授权 + 输入校验、服务端 fetch 的 SSRF、安全响应头/CSP、认证/会话/Cookie、速率限制；(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) 自查清单。仅防御，不含攻击步骤。
Express（Node.js）安全 —— 生产环境加固实务参考
Express 是极简框架 —— 默认几乎不守护任何东西，防御要靠你自己添加。本页是一份可上手的实务参考：(1) 按优先级排序的加固清单（P0–P2），(2) 分领域的具体对策 —— 安全响应头（helmet）+ 禁用 x-powered-by、npm 依赖 CVE、输入校验与注入（SQL/NoSQL 运算符）、认证与所有者范围授权、限流与大小上限、会话/Cookie/CSRF、SSRF、生产错误处理（不暴露堆栈）、NODE_ENV，以及 (3) 自查清单。仅讲防御，不含攻击步骤。
Ruby on Rails 安全 — 生产环境加固实务参考
Rails 自带约定和安全默认值（CSRF 防护、Strong Parameters、ORM），但生产事故来自运营。这是一份实务参考：(1) 优先级排序的加固清单（P0–P2）；(2) 分领域指引——密钥与 credentials（master key/secret_key_base）、生产环境配置（force_ssl、不暴露异常）、gem CVE、Strong Parameters/Mass Assignment、授权（Pundit、所有者范围）、注入与危险方法（where 拼接/send/constantize）、会话/Cookie/CSRF、SSRF/上传；(3) 自查清单。仅防御，不含攻击步骤。
加了登录就以为安全了吗 — 认证与授权的区别
认证＝确认『你是谁』；授权＝决定『这个人可以做什么』。两者是两回事，只加一个登录并不等于做了授权。数据若没有按所有者（user_id）做收窄，就会变成『登录 = 看到全部数据』——OWASP 排名第一的 Broken Access Control（访问控制缺陷）。再叠加上认证脚手架默认开放的注册功能，陌生人就能注册后直接进来。防御：把每一条查询都收窄到所有者／关闭不需要的注册／对管理面做纵深防御／在事故发生之前就备好审计与访问日志／检测新注册。
IDOR 是什么 — 仅靠改写 ID 就能看到他人数据的漏洞
IDOR 是一种仅靠把 ?id=124 改成 125 就能看到他人发票、个人信息的访问控制缺陷漏洞。关键防御是「在服务端每次校验『当前登录的这个用户，是否可以查看该对象』」。难以猜测的 ID 并不能算作对策。