文章总结： 本文披露了NASA门户网站因LiferayJSONWSAPI未鉴权导致的高危数据泄露。作者利用前端JS泄露的companyId，直接调用get-company-users接口获取了1.8MB敏感用户信息。文章分析了该漏洞在定向社工方面的危害，并强调了只读接口权限校验的重要性，指出NASA已修复此问题，强调了安全意识与手动测试的价值。 综合评分： 86 文章分类： 渗透测试,漏洞分析,WEB安全,数据泄露

---

1.8MB 的一个失误：通过 Liferay API 泄露数千名政府用户信息

haidragon

安全狗的自我修养

2026年1月5日 12:13 湖南

官网：http://securitytech.cc/

#

我只是向服务器问了一个很简单的问题，它却把整本电话簿都回给了我。

按 Enter 或点击查看原图

---

我们通常会把“黑客攻击”想象成那种又吵又复杂的东西：

• 内存破坏
• 加密漏洞
• 反序列化利用链

但在现实世界中，最危险的漏洞往往极其简单。

它们出现的原因通常只是服务器做了一个假设：

“既然有人在请求这些数据，那他肯定有权限看。”

API 不会思考。 它们不会问为什么。 它们只检查你请求了什么 —— 有时候甚至连这一步都省了。

这就是我如何在一个 NASA 门户网站 上发现一个 隐藏、无需认证的 API 接口，并在不爆破、不登录、不碰认证页面的情况下，直接导出了 1.8MB 的个人敏感信息（PII）。

我所做的，只是——礼貌地问了一下。

---

🕵️ 侦察阶段：“这玩意儿跑在什么东西上？”

在枚举子域名的过程中，有一个 NASA 的门户网站立刻引起了我的注意。

它的行为不像 WordPress， 界面也不像 Drupal。

但我注意到了几个细节：

• Cookie 名称中有 LJSESSIONID
• URL 中包含 /web/guest
• JavaScript 很重，页面加载缓慢（这通常是个线索）

快速指纹识别后，结果很明确：

👉 Liferay Portal

Liferay 是企业级 Java 门户软件。 功能强大、模块化程度高，而且——极其容易被错误配置。

最关键的是： Liferay 自带一个 内置 API 浏览器，叫做 JSONWS（JSON Web Services）。

而这种“内部工具”，非常容易被直接暴露到公网。

---

🧭 发现阶段：意外得到的 API 地图

我做了最基础、最不起眼的一步侦察：

https://[Target].nasa.gov/api/jsonws

结果是——

页面直接打开了。

没有认证提示。 没有警告横幅。 只有一个干净整洁的开发者文档页面，列出了服务器上所有可用的后端 API 方法。

我眼前的东西，本质上就是一张应用内部结构的交互式地图：

• add-user
• delete-group
• update-role
• get-company-users

这就好比你发现了一个银行金库，而且旁边还贴着一张“所有抽屉位置索引表”。

---

🧩 拼图阶段：“几乎都锁上了……除了一个”

大多数接口的行为都是正确的。

我点了 add-user。

返回结果是：

{"exception":"AuthenticatedAccessRequired"}

很好，这正是我们希望看到的。

但随后，有一个接口吸引了我的注意：

/user/get-company-users

接口说明是：

返回某个公司下的所有用户

所需参数：

• companyId（整数）

🚩 危险信号。

一个只读接口，却能返回所有用户信息，本身就已经很危险了。 但真正的问题是：

它受保护了吗？

---

🧠 捷径：寻找 Company ID

我测试了几个值：

companyId=1    → []
companyId=100  → []

暴力枚举 companyId 是可行的，但会制造噪音。

于是我做了一件前端开发者最不希望攻击者做的事：

我打开了 Chrome DevTools（开发者工具）。

在控制台里输入：

Liferay

返回了一个全局对象。

展开：

Liferay.ThemeDisplay

就在这里，明文显示着答案：

companyId: 20116

前端渲染页面需要这个值。 而我，只是用它来导出整个用户目录。

不同的目的，同一个变量。

---

💥 利用阶段：“API 就这么……回答了”

我手工构造了请求：

https://[Target].nasa.gov/api/jsonws/user/get-company-users
  ?companyId=20116
&start=0
&end=99999

没有请求头。 没有 Token。 没有工具。

只是一个浏览器。

我按下回车。

浏览器标签页卡住了。

转圈。 CPU 占用飙升。 我一度以为把门户给打崩了。

然后，响应出来了。

---

📦 数据泄露结果

1.8MB 的 JSON 数据。

成千上万条记录。

每一条都包含：

{
"userId":30512,
"emailAddress":"[email protected]",
"firstName":"John",
"lastName":"Doe",
"jobTitle":"Senior Propulsion Engineer",
"lastLoginDate":1698234110000,
"screenName":"jdoe"
}

我能访问到的信息包括：

• 用户真实姓名
• 官方政府邮箱地址
• 职位头衔
• 内部用户名
• 用户 ID

而我从未进行过任何认证。

原因是什么？

这个接口被标记为 Guest Accessible（访客可访问） —— 可能是为了支持某个内部“员工通讯录”功能。

但前端的“访客”，在后端直接变成了：

👉 “互联网上的匿名用户”

---

⚠️ 影响分析：为什么这是 P2（高危）

常见的一种反驳是：

“员工信息在 LinkedIn 上也能找到。”

这个说法在这里完全站不住脚，原因有三点：

---

1️⃣ 完整性

LinkedIn 是可选的。

而这个 API 返回的是该门户下的全部用户，包括那些从不使用社交媒体的人。

---

2️⃣ 用户名

拿到用户名（比如 jdoe），直接干掉了一半的撞库难度。

你不再需要猜用户名。 你已经拥有它了。

---

3️⃣ 精准钓鱼攻击

职位信息可以把普通钓鱼邮件升级为定向社工攻击：

“Hi John，作为 Artemis 项目的高级推进工程师，请你审阅附件文档……”

这不是垃圾邮件。 这是高成功率的定向社会工程攻击。

---

🛡️ 修复措施 & 负责任披露

我第一时间通过官方渠道提交了漏洞报告。

NASA 的响应迅速且专业。在漏洞分级过程中，他们指出我描述的部分影响涉及 内部拒绝服务（DoS）条件，这一点被认定为不在漏洞赏金计划范围内。

不过，他们依然非常重视这个问题，并采取了完整的修复措施，彻底消除了根本风险：

• 禁用了 /api/jsonws 的公网访问
• 为 get-company-users 增加了严格的 ACL 权限校验
• 将该接口限制为仅管理员角色可访问

虽然 DoS 角度被视为不在范围内，但这些修复彻底解决了未认证数据泄露问题，并整体强化了门户的安全性。

---

🎓 经验教训

1️⃣ 只读 ≠ 安全

开发者往往紧盯：

• POST
• PUT
• DELETE

而攻击者最爱研究的是：

👉 GET

信息泄露通常是更大攻击链的第一步。

---

2️⃣ 依赖“没人知道”的安全假设一定会失败

这里的假设包括：

• “没人知道 JSONWS”
• “没人知道 companyId”

结果两条都错了。

API 的上下文信息到处都是，尤其是在前端 JavaScript 里。

---

3️⃣ 好奇心比扫描器更重要

没有任何自动化扫描器发现这个问题。

真正起作用的是一个人的疑问：

“这个东西为什么存在？” “如果我试试这个值会发生什么？”

这种思维方式，比任何工具都重要。

---

🚀 最后的话

这个漏洞不是来自爆破。 不是来自 0day。

它来自于——信任。

• 信任没人会去问
• 信任只读接口是无害的
• 信任前端数据不会被滥用

服务器不知道你的意图。 它们只认识参数。

而有时候，只要你问对了问题……

它们就会把整本电话簿交给你。

Happy Hacking! 🕵️‍♂️

• 公众号:安全狗的自我修养
• vx:2207344074
• http://gitee.com/haidragon
• http://github.com/haidragon
• bilibili:haidragonx

#

• 

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全狗的自我修养 haidragon《1.8MB 的一个失误：通过 Liferay API 泄露数千名政府用户信息》