access control
该标签下有 16 篇文章
Toypo应用遭未授权访问（据Toypo称，受影响用户697,209人）：手机号码、姓名和地址外泄，门店应用用户该怎么做
Toypo Inc.确认，其客户管理应用Toypo应用于2026年10月4日遭到第三方未授权访问，并在10月14日的通知中表示，涉及用户为697,209人，其信息可能已外泄。另一份没有日期、也没有人数的Toypo通知页面则称信息已外泄。自10月13日起，公司已逐一联系相关用户，包括通过应用内推送通知。据公司称，其系统的一部分存在访问控制缺陷，使已通过认证的用户能够获取无权查看的其他用户信息，日志显示有第三方利用它获取了用户信息。该缺陷已被修复。可能外泄的信息为手机号码和用户ID等标识符，以及（如已登记）姓名、姓名假名读音、电子邮件地址、出生日期、性别和地址。公司称，密码等登录凭据、信用卡号等支付数据、积分、到店记录以及购买或使用记录不在其中，用户无需更改密码或在应用内采取其他措施。目前尚未确认有具体的次生损害。公司已向个人信息保护委员会报告，并正在安排第三方安全评估。在使用该应用的门店发布的通知中，JR Kyushu Food Service称约61,500名注册会员中约26,900人受影响，Mannoya称其Kineya Mannoya官方应用的212名会员中有12人受影响。Toypo的联系电话为0120-546-030（工作日日本时间9:00至18:00；呼叫中心受理电话至10月30日18:00，此后请使用应用内联系方式）。本站的结论是：能准确说出您的手机号码和姓名的消息，未必是真的。请勿使用其中的链接或号码，而应通过应用内联系方式或通知中列出的联系方式核实。
Commune未经授权访问事件（按社区计算的166,505名会员记录）：企业社区会员数据泄露——会员和运营者应当怎么做
2026年10月9日，Commune Inc.宣布，其面向企业的社区服务Commune和Commune for Work遭外部第三方未经授权访问，部分社区的会员数据发生泄露。泄露时段为10月5日约18:00至10月6日约21:00，以及10月7日13:17至14:36（日本时间）。其首次通告给出的可能受影响的最高人数约为307,000人（为唯一人数的估计）。在10月21日的后续通告中，该公司在详细调查后确认，有166,505名会员受影响（按每个社区统计会员ID后的合计，因此同时加入多个社区的人会被重复计算；包括公司自营社区及测试/演示社区，不包括攻击者创建的账户），其中125,601人的数据包括电子邮件地址在内遭泄露。其他会员泄露的数据包括显示名称、个人资料和私有群组成员身份。144名会员的密码在未经其操作的情况下被更改为临时密码。目前未确认密码本身或私信内容泄露，该公司也不持有支付数据。公司将事件归因于非法获取的私有社区邀请链接以及对管理员的冒充。使用该服务运营社区的客户公司也发布了通告；JMAM表示，其Toki Labo社区会员资料中的姓名、住址、年龄和电话号码也遭泄露。为防止泄露的电子邮件地址被滥用，Commune Inc.自10月10日00:50起因紧急维护暂停了所有社区，并采取了强制管理员账户使用双重验证等措施。10月16日，该公司宣布将分阶段重新开放社区，首先面向提出申请的客户，且仅限网页浏览器版本，部分功能受限（应用程序、使用电子邮件地址的新注册以及“忘记密码”重置仍不可用）。该公司表示，在维护和测试期间未发现新的未经授权访问或泄露。10月21日的后续通告还称，公司已于10月9日向总务省（关东综合通信局）提交了初步报告，已开始向警方咨询，在分析全部日志后未发现攻击者遗留的程序、账户或设置，并正在筹备由第三方机构进行的取证调查。本站观点：请查看运营您所在社区的公司的通告，确认您是否受影响，并且不要打开声称来自该社区的邮件中的链接。
NewsPicks 数据泄露（持卡人姓名及卡号末位数字，最多362,000条记录）：内部管理工具遭入侵的情况及用户应采取的措施
2026年10月8日，Uzabase株式会社宣布，其新闻服务NewsPicks运营中使用的一个管理工具遭第三方未经授权访问，部分用户的个人数据可能已泄露。其10月9日发布的第二份通知称，此次入侵利用了该管理工具的一个漏洞，并给出了各项目的最大估计数量：用于网络支付的部分卡片数据（持卡人姓名及卡号后3或4位等）362,000条；电子邮件地址323,000个；职位级别类别273,000条；所属单位65,000条；姓名59,000条；其他。公司表示，完整卡号和安全码从未存储在其系统中，也未泄露；尚未确认密码泄露。目前未确认二次损害。本站的观点是：一条引用了您卡号末位数字或雇主信息的消息，并不能证明它是真实的。请勿打开链接，通过官方应用或您自己打开的官方网站核对，并留意您的信用卡账单。
skyticket（Adventure Inc.）数据泄露（约1464万条记录）：密码、退款银行账户信息及部分用户的卡信息外泄——用户今天应该做什么
2026年10月9日，Adventure Inc.宣布其旅游比价及预订网站skyticket发生三起各自经由不同路径的未经授权访问事件。第一起中，某管理功能被滥用，并被用作进入其他服务器及云端存储数据的起点；约1464万条记录泄露，包括姓名（含护照拼写）、出生日期、电子邮件地址、电话号码、地址以及用于银行转账的汇款人姓名，其中约413万条包含哈希处理的会员密码。第二起中，一个业务管理系统的漏洞被利用，17,780条记录（含重复记录，仍在统计中）包含退款银行账户信息，已泄露或可能已泄露。第三起中，巴士预订完成页面无需登录即可显示，约12,000笔预订已被或可能已被查看。公司最初表示卡号不在泄露数据之列，但在10月16日的第二份通知中更正：2017年2月至2018年6月期间注册或使用信用卡支付“skyticket Premium”会员费的最多6,140人，其卡号、持卡人姓名和有效期（部分人仅为卡号；不含安全码）在第一起事件中泄露，同时泄露的还有作为Premium会员福利提供的福利服务的会员ID、姓名和密码。护照图像未外泄；截至10月9日的通知，已确认的次生危害仅为一次会员账户的未授权登录（第二份通知未说明已泄露的卡信息是否被滥用）。本站的建议：会员应立即在官方网站或应用程序中修改密码；凡使用过相同密码的其他服务，也应一并修改；若在此期间注册或使用卡支付Premium会员费，应检查2026年10月起的卡账单；忽略关于退款、赔偿或预订变更的信息；绝不向任何人提供银行密码或一次性验证码。
云存储被公开暴露：即使开启了「阻止公有访问」，数据也可能泄露
存储桶泄露来自配置，而不是攻击。文档里最关键的一句是：阻止公有访问的设置不会修改现有的策略或 ACL——公开设置留在阻止层下面，一旦解除阻止，公开访问就会恢复。所以目标不是「已开启阻止」，而是「关掉阻止也没有任何东西是公开的」。要在账户级别启用，因为存储桶策略可以授予别人关闭存储桶级阻止的权限。而且「公开」的定义比大多数人想象的更宽。
文件上传漏洞——从设计上防止 Web Shell 和 RCE
上传漏洞的问题不在于「接收了文件」，而在于放在哪里、能否被执行。未认证的端点＋没有类型校验＋存放在 Web 根目录下＋那里可以运行脚本＝Web Shell → RCE。用多层来防御：（1）端点上的认证/权限＋CSRF，（2）服务器端白名单＋内容检查，（3）存放在 Web 根目录之外（或禁止执行），（4）随机化文件名，绝不信任用户提供的路径。不要只依赖一项控制，要让每一步都有能拦住攻击的东西。
OWASP Top 10 是什么：Web 应用十大安全风险的权威清单
OWASP Top 10 是非营利组织 OWASP 每隔数年发布一次的『Web 应用十大最严重风险』清单，被广泛用作开发者与运营者的共同语言。现行的 2025 年版（2025 年 11 月公布）仍以『访问控制缺陷（Broken Access Control）』居首；安全配置错误升至第二，并新增了『软件供应链失败』和『异常情况处理不当』两个类别。SSRF 被并入访问控制缺陷。它们是风险的『类别』而非单个攻击手法，正确用法是把它当作审视自己应用的观点。
PCI DSS 是什么：处理信用卡数据所需遵守的安全标准
PCI DSS（Payment Card Industry Data Security Standard）是存储、处理或传输卡数据的商户需要满足的国际安全标准，由各卡组织制定，要求网络保护、存储数据加密、最小权限访问控制、监控/日志、脆弱性管理等。实务中最安全的做法是：干脆不要自己持有卡号，把卡处理交给合规的支付服务商（令牌化），从而把适用范围缩到最小。
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) 自查清单。仅防御，不含攻击步骤。
Express（Node.js）安全 —— 生产环境加固实务参考
Express 是极简框架 —— 默认几乎不守护任何东西，防御要靠你自己添加。本页是一份可上手的实务参考：(1) 按优先级排序的加固清单（P0–P2），(2) 分领域的具体对策 —— 安全响应头（helmet）+ 禁用 x-powered-by、npm 依赖 CVE、输入校验与注入（SQL/NoSQL 运算符）、认证与所有者范围授权、限流与大小上限、会话/Cookie/CSRF、SSRF、生产错误处理（不暴露堆栈）、NODE_ENV，以及 (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) 一份自我验证清单。仅限防御——不含攻击步骤。
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 并不能算作对策。