跳转至

Exploiting vulnerabilities in Johnson & Johnson web apps

Ch12.070 Exploiting vulnerabilities in Johnson & Johnson web apps

📊 Level ⭐⭐ | 6.2KB | entities/eaton-works-jnj-webapp-vulnerabilities.md

Exploiting vulnerabilities in Johnson & Johnson web apps

摘要

Eaton Works 安全研究员公开披露了强生（Johnson & Johnson）两个 Web 应用中的真实漏洞。 第一个是校园招聘系统，因后端使用硬编码 API 密钥而非 MSAL token 验证，导致近 1000 名学生信息泄露；第二个是内部审计跟踪管理系统（ATMS），被 20 家关联公司使用，通过 IDOR（不安全的直接对象引用）实现管理员接管。两个漏洞均于 2025 年 10 月报告给强生，但修复进展缓慢，直到 2026 年 6 月文章发布时仍在协调中。

核心要点

漏洞一：校园招聘系统 — MSAL 认证绕过

强生的校园招聘网站使用 Microsoft Authentication Library (MSAL) 进行前端认证，但 后端从未验证 MSAL token。后端 AWS API 实际使用硬编码 API 密钥进行身份验证。

攻击路径： 1. 修改前端 MSAL 代码，使其始终返回「已登录」状态 2. 直接访问招聘人员路由和后端 API 3. 后端使用硬编码密钥验证，完全忽略 MSAL token 4. 获取所有学生信息、面试评分和招聘人员笔记

根本原因：前端唯一认证（frontend-only authentication）— 后端不验证 token 有效性，静态 API 密钥无法区分用户身份。

漏洞二：内部审计系统 — IDOR 管理员接管

ATMS（Audit Tracking Management System）是强生及 20 家关联公司（包括 LifeScan、Ethicon、Janssen、Abiomed 等）使用的内部审计管理 Web 应用。

攻击路径： 1. 访问网站时立即重定向到 Microsoft SSO 登录页，但 ReactJS 应用已下载，暴露所有 API 端点 2. 调用 getAllUsers API，无需认证即返回 13,600 名强生员工数据 — 这证明所有 API 均无认证保护 3. 从帮助页面获取系统管理员的用户名和 WWID 4. 通过 MSAL 代码 patch 停止登录重定向，在 localStorage 中硬编码管理员凭据 5. 调用会话创建 API（GET 请求）获取有效 session GUID 6. 完成管理员接管，可切换 20 家公司的审计数据

额外发现：系统使用了幼稚的客户端加密方案来混淆某些秘密值，但这种安全性仅是表面文章。

深度分析

前端认证的系统性缺陷

两个漏洞的核心问题完全一致：将认证职责委托给前端，后端不做独立验证。这是企业 Web 应用中最常见也最危险的反模式之一。

MSAL 等前端认证库的作用仅限于 UI 层面的访问控制（隐藏/显示界面元素），它们不提供任何后端安全保障。当开发者将 MSAL 集成视为「完成了认证」时，实际上只是在客户端做了一个可被轻易绕过的门面。

[错误模式]
Browser → MSAL check (前端) → UI 渲染控制
Browser → API call → 后端（无 token 验证，使用静态密钥）

[正确模式]
Browser → MSAL check (前端) → UI 渲染控制
Browser → API call + Bearer token → 后端（独立验证 token 有效性、权限范围、用户身份）

企业安全中的 IDOR 持久性

IDOR 在 OWASP Top 10 中长期占据高位，但在 2026 年的企业应用中仍然普遍存在。ATMS 案例展示了 IDOR 的典型升级路径：

  • 信息泄露：getAllUsers 端点暴露全部员工数据
  • 权限提升：通过已知用户名和 WWID 伪造管理员身份
  • 横向移动：系统支持在 20 家公司间切换，无租户隔离

20 家公司共享同一系统而无服务端租户隔离，这违反了多租户架构的基本安全原则。

漏洞披露时间线的启示

两个漏洞于 2025 年 10 月报告给强生。作者指出，与 2024 年的报告经历（「stellar — immediate action」）相比，此次体验「less positive」。 这反映出大企业在漏洞响应流程中可能存在的退化：当安全团队扩大后，协调成本和内部优先级冲突可能拖慢修复进度。

安全工程启示

  1. 前端认证 ≠ 认证：MSAL 检查仅影响 UI 渲染，后端必须独立验证 token 的有效性、过期时间和权限范围
  2. 硬编码 API 密钥 = 无认证：静态密钥无法区分用户身份，应使用短期 token（如 OAuth2 Bearer token）并绑定用户上下文
  3. IDOR 仍是 #1 Web 漏洞：在 2026 年的企业应用中仍然频发，说明安全开发生命周期（SDL）的执行力度不足
  4. 多租户隔离必须在服务端强制执行：20 家公司共享系统而无租户隔离，意味着任何一次认证绕过都是全量数据泄露
  5. 客户端代码是公开代码：React/JS 应用的所有代码均可被逆向工程，任何依赖客户端逻辑的安全机制都不可信
  6. 安全审计应覆盖第三方依赖：使用 MSAL 不等于安全，需要验证集成方式是否正确

实践启示

对于企业 Web 应用开发者： - 在 API 网关层统一实施 token 验证，不依赖各服务自行验证 - 使用 零信任架构 原则，每个 API 调用都必须携带并验证认证凭证 - 实施自动化 IDOR 检测（如 Burp Suite 的 Autorize 插件）作为 CI/CD 流水线的一部分 - 对涉及多租户的系统，必须在数据库查询层强制 tenant_id 过滤

相关实体