事件背景
作为博客维护者,我们总是希望与读者保持良好的互动,评论功能就成为了必不可少的交流渠道。然而,在 2025 年 11 月,我的 Halo 博客系统遭遇了一次 XSS 攻击,导致评论管理功能受损。
这次攻击给我敲响了警钟,也让我深刻认识到数据备份和安全防护的重要性。今天就把这次完整的事件记录分享给大家,希望能帮助到遇到类似问题的朋友。
问题现象
攻击者通过直接调用接口提交了两条特殊的评论:
[XSS](javascript:alert(1))- 明显的 XSS 攻击代码test comment- 普通的测试评论

在这之后,Halo 的评论管理页面出现了以下异常:
- 评论列表页面完全无法访问
- 但可以正常打开"精选评论"和"最近评论"
- 页面显示"服务器内部发生错误,请稍后再试"

这个问题让我非常困扰,因为评论管理功能完全无法使用,影响了我与读者的互动。
问题原因分析
经过 GitHub 社区技术大佬的深入排查,我们发现了问题的根本原因:
数据库中的这两条异常评论数据缺少 spec.subjectRef 必需的 version 字段
这很可能是攻击者绕过前端直接调用 API 接口导致的。
技术细节说明
在 Halo 的数据库结构中:
spec.subjectRef是一个引用字段,用于关联评论与对应的文章/页面- 完整的引用应该包含
name、kind和version三个必要字段 - 攻击者通过非正常途径创建了数据结构不完整的评论记录
- 当管理界面尝试加载这些损坏的数据时,由于无法正确解析引用关系,导致服务器抛出内部错误
数据结构对比
正常的评论数据结构:
{
"spec": {
"subjectRef": {
"name": "post-abc123",
"kind": "Post",
"version": "v1alpha1" // 这个字段是必需的
}
}
}
损坏的评论数据结构:
{
"spec": {
"subjectRef": {
"name": "post-abc123",
"kind": "Post"
// 缺少 version 字段
}
}
}
解决方案
方案一:使用 Data Studio 可视化修复(推荐)
这是最直观安全的修复方式,通过 Halo 官方插件进行操作修复损坏的数据。
步骤 1:安装 Data Studio 插件
- 登录 Halo 后台管理界面
- 找到"插件"菜单
- 搜索并安装"数据工厂(Data Studio)"插件
步骤 2:定位异常数据
- 进入"工具" → “Data Studio”
- 在 Comment 表中找到异常的评论数据
- 可以通过关键词搜索或按时间排序找到可疑评论

步骤 3:修复数据结构
- 点击异常评论数据进入编辑页面
- 找到
spec.subjectRef字段 - 注意:直接删除会卡在"删除中"状态无法成功

- 需要在
spec.subjectRef中添加缺失的字段:"version": "v1alpha1"

步骤 4:完成修复
- 保存修改后,数据恢复正常状态
- 此时可以顺利删除恶意评论
- 刷新评论管理页面,确认问题已解决
优点:
- 图形化界面操作,直观易懂
- 不需要直接操作数据库
- 安全性高,适合不熟悉数据库的用户
方案二:直接使用 SQL 删除恶意评论
对于熟悉数据库操作的用户,可以通过 SQL 命令快速处理。
步骤 1:查找包含 XSS 代码的评论记录
SELECT name FROM extensions
WHERE convert_from(data,'UTF8') LIKE '%javascript:alert(1)%';
执行结果示例:
/registry/microimmersion.webjing.cn/recentcomments/recent-comment-xbr6ag5e
/registry/content.halo.run/comments/1ca2d9b4-18cb-41a3-b179-509e2817fd4e
步骤 2:删除识别出的恶意评论
-- 删除恶意评论记录
DELETE FROM extensions
WHERE name='/registry/microimmersion.webjing.cn/recentcomments/recent-comment-xbr6ag5e';
DELETE FROM extensions
WHERE name='/registry/content.halo.run/comments/1ca2d9b4-18cb-41a3-b179-509e2817fd4e';
注意事项:
- 操作前务必备份数据库
- 确认删除的是恶意评论,不要误删正常数据
- 建议先在测试环境验证
什么是 XSS 攻击?
XSS(跨站脚本攻击) 是一种常见的网络安全漏洞,攻击者通过在网页中注入恶意脚本,当其他用户浏览该页面时,这些脚本会被执行,从而盗取用户信息、会话 cookie 等敏感数据。
XSS 攻击的常见类型
- 存储型 XSS:恶意脚本被存储在服务器数据库中,当其他用户访问时执行
- 反射型 XSS:恶意脚本通过 URL 参数反射回页面
- DOM 型 XSS:通过修改页面的 DOM 结构执行恶意脚本
本次事件的特点
在此次事件中,攻击者不仅实施了典型的 XSS 代码注入,还通过直接调用 API 绕过了前端的数据完整性校验,造成了更深层次的影响:
- 前端表单验证被绕过
- 数据结构完整性被破坏
- 影响了系统的正常运行
总结
这次事件给我留下了深刻的教训:
1. 备份是关键
定期备份真的很重要!如果此次事件中,我有良好的备份习惯,就可以快速恢复数据,避免花费大量时间排查和修复问题。
建议的备份策略:
- 每天自动备份数据库
- 每周备份完整系统
- 备份文件保留至少 30 天
- 异地备份,防止单点故障
2. 安全防护不能松懈
- 及时更新系统到最新版本
- 启用所有安全相关的插件和配置
- 定期检查系统日志
- 关注官方安全公告
3. 社区支持很重要
特别感谢 GitHub 社区技术大佬提供的深度分析和技术支持。在遇到问题时,积极寻求社区帮助往往能更快地找到解决方案。
希望这篇记录能帮助到遇到同样问题的朋友!如果你有其他安全防护建议或遇到类似问题,欢迎在评论区交流。
相关资源:
免责声明:本文基于真实安全事件撰写,旨在分享问题排查和解决经验,不构成任何安全建议。请根据实际情况采取适当的防护措施。
默认评论
Halo系统提供的评论