以前 18 年的时候因为做的是安全漏扫开发的工作，所以那段时间经常接触 CVE 漏洞，但是有时候会被一些垃圾 CVE 气的缓不过气来，所以为了证明 CVE 可以真的很水，当时我自己也水了几个 CVE（打不过就加入？），如今时隔 3 年了，正好赶上博客大改版，那就顺便来水一篇文章，教大家如何水一个 CVE 吧。

事情起因

全站浏览量和评论最高的文章前几天发现了一个致命的问题，就是评论突然无法正常加载了：

因为博客最近改版，Valine 也换的最新版本，可能是哪个评论和这个 Valine 冲突了，所以下面来尝试找出罪魁祸首并恢复原文评论。

排查问题

备份评论

首先在 LeanCloud 中「按条件过滤」出所有 Termux 文章下面的评论：

然后将筛选后的结果导出为 JSON 格式的文：

这样就备份评论成功了。

尝试恢复

LeanCloud 自带的评论恢复功能基本上是不能使用的，首先「备份恢复」功能只有商用版本可用：

使用「数据导入」的功能，结果是覆盖式导入：

当时差点就把我的「Comment」类下的 2.3k 个评论给覆盖了（巨坑呀 一不小心可能就重头再来了）：

没办法只能想其他办法了。

脚本恢复

LeanCloud 支持一个个手动添加行，类似于这样的效果：

现在思路就是抓取添加行的数据包，看看能不能使用脚本自动化读取之前的 JSON 文件添加进去，经过 Fuzz 测试发现可以自动化添加，最终的脚本如下，相关说明都放注释里面了：

import jsonimport requests# 读取 json 文件并返回数组def get_comments(path): with open(path, 'r', encoding='UTF-8') as jsonfile: json_list = json.load(jsonfile) return json_listdef main(): # 这个是抓取提交评论的数据包的 URL url = "https://cn-n1-console-api.leancloud.cn/1.1/classes/Comment?fetchWhenSave=true" headers = { "Host": "cn-n1-console-api.leancloud.cn", "X-Lc-Ua": "LeanCloud-JS-SDK/0.0.26(Browser)",... 这里老老实实填写抓包时候的 headers ... "Accept-Encoding": "gzip, deflate" } # 读取 termux.json 位置的文件 comments = get_comments('termux.json') # 对评论进行切片 comment = comments[:50] # 考虑到评论互相引用的情况，所以得有 pid 和 rid if 'pid' in comment: pid = comment['pid'] rid = comment['rid'] else: pid = "" rid = "" # 提交评论的基础格式 data = { "ACL": {"*": {"read": True}}, "isNotified": False, "pid": pid, "rid": rid, "comment": f"{comment['comment']}", "objectId": f"{comment['objectId']}", "insertedAt": { "__type": "Date", "iso": f"{comment['insertedAt']}" }, "createdAt": { "__type": "Date", "iso": f"{comment['createdAt']}" }, "link": f"{comment['link']}", "mail": f"{comment['mail']}", "nick": f"{comment['nick']}", "ua": f"{comment['ua']}", "url": f"{comment['url']}" } # 发起提交评论的请求 r = requests.post(url=url, headers=headers, data=json.dumps(data))if __name__ == '__main__': main()

找出问题

几百个评论如何找出哪些评论出问题了呢？实际上主要调整如下代码即可：

# 读取 termux.json 位置的文件comments = get_comments('termux.json')# 对评论进行切片comment = comments[:50]

通过comments[:50] 先导入前 50 个评论，如果网页刷新正常的话，再导入comments[50:100] 50-100个评论，以此类推可以很方便的找出问题评论，最终找出的 BUG 评论如下：

找到了罪魁祸首，这个评论插进去，我的评论就挂了。简单 Fuzz 发现根本问题出在了 UA 里面，这个用户评论的 UA 很短，新版本的 Valine 会根据用户的 UA 会识别用户的操作系统和浏览器类型，因为这个 UA 很短，直接导致 Valine 的相关 JS直接异常，从而导致整个评论挂了。

验证危害

为了验证我这个情况不是个例，网上寻找其他使用了最新版 Vaine 的 Hexo 博客试试看，锁定了一个目标：

评论抓包改下 UA：

发包，成功将对方页面评论打瘫掉：

OK 这个虽然是一个很没有技术含量的 BUG，但是找到这个小 BUG 也消耗了不少时间，所以与其花了这么多时间不如用这个 BUG 去水一个 CVE，毕竟 Valine Github 上面也开源了，也有过千的 star，那么下面就开始去提交这个 CVE 吧。

提交 CVE

编写细节

提交 CVE 前首先得说明一下漏洞细节，可以是个人文章也可以是直接 Github 对应的项目提交 issue，国光我这里就直接在 Valine 项目下提交了 issue：

a fatal bug that can kill the comment system（用户恶意修改 UA 评论 可影响正常评论加载） #366

小细节就是尽量使用英文去描述漏洞细节，如果你英语像我一样不太行的话可以使用谷歌翻译，总之可以让老外读懂漏洞的来龙去脉就行了。

提交 CVE

提交 CVE 的官网地址为：https://cveform.mitre.org

下面我帖一下本次申请的表单填写情况。

• 「 Select a request type」我这里选择的是：Report Vulnerability/Request CVE ID，即报告漏洞或申请 CVE ID
• 「Enter your e-mail address」填写自己的邮箱信息用于接收 CVE 编号：admin@sqlsec.com
• 「Number of vulnerabilities reported or IDs requested (1-10)」报告的漏洞或请求的 ID 数，国光填的默认1

勾选一下「漏洞不在 CNA 列表」和 「漏洞没有被申请过 CVE 编号」：

• 「Vulnerability type」这里根据自己的情况选择漏洞类型，因为我这个 BUG 不好定义，所以填写了 Other or Unkown

• 「Other vulnerability type」因为上面漏洞类型选择的 Other，所以需要对这个漏洞进行简短的说明，国光的说明内容如下：

  a fatal bug that can kill the comment system,Similar to DDOS

• 「Vendor of the product(s)」 产品供应商，国光这里填写的是：Valine

• 「Affected product(s)/code base」受影响的产品/代码库，根据情况填写 Valine 版本为 1.4.14

• 「Has vendor confirmed or acknowledged the vulnerability?」供应商是否确认或承认漏洞，这里当然选择 Yes

• 「Attack type」攻击类型，这里 Web 攻击大多数 Remote远程的

• 「Impact」影响的话，国光这里勾选了Denial of Service

• 「Affected component(s)」受影响的组件，这里可以填写问题代码、影响的功能等

• 「Attack vector(s)」攻击向量，主要就是漏洞利用的 Poc，国光原文内容如下：

  "ua":"Mozilla/5.0",Details can be seen in https://github.com/xCss/Valine/issues/366

  主要就是贴了核心 Poc 和 Github 详情

• 「Suggested description of the vulnerability for use in the CVE」在 CVE 中使用的建议和描述：

  Valine 1.4.14 allows remote attackers to cause a denial of service (application outage) by supplying a ua (aka User-Agent) value that only specifies the product and version.

  这块的最终的呈现效果如下：

  

• 「Discoverer(s)/Credits」漏洞发现者或者组织，国光这里填的是www.sqlsec.com

• 「Reference(s)」漏洞参考链接，这里贴一下之前提交的 issue：https://github.com/xCss/Valine/issues/366

最后填写验证码提交我们上面填写的表单即可：

过程概览

提交完之后，上述 CVE 申请的邮箱会很快收到应该邮箱：

大概意思就是你提交的漏洞我们收到了，这个漏审核成功有 CVE 编号了再通知你。

如果漏洞比较合规的话，可以很快收到 CVE 编号的回复邮件：

可以看到中午提交漏洞，晚上就收到 CVE 编号的邮件了，效率比我 18 年的时候快了很多（18 年的时候基本上得两三天时间）

在邮件的后面几可以找到自己的 CVE 编号了：

本次申请的 CVE 编号为：CVE-2021-34801

谷歌一下，发现今天很多网站已经收录了：

Bingo，完整的 CVE 申请流程就是这个样子了，过一段时间后国内的 CNVD 也会收录这个 CVE 漏洞，然后再分配一个 CNVD 编号的，溜了溜了，差不多到这就结束了，老头打了个响舌nice.mp4

文章总结

CVE 的话更多的还是圈外人看起来比较高大上，实际上懂得都懂，CVE 编号多并不算什么，如果你很多比较水的 CVE 的话，只能说你这个人像国光我一样比较闲得蛋疼，所以追根到底还是看漏洞质量！建议大家水 CVE 点到为止即可。

下面分享应该 Hackerone 上一个价值 $11214 的漏洞：

https://hackerone.com/reports/1065500 （Multiple bugs leads to RCE on TikTok for Android）

漏洞详情已经披露了，可参考：TikTok for Android 1-Click RCE

这才是真的牛皮！！！

支持一下

本文可能实际上也没有啥技术含量，但是写起来还是比较耗费时间的，在这个喧嚣浮躁的时代，个人博客越来越没有人看了，写博客感觉一直是用爱发电的状态。如果你恰巧财力雄厚，感觉本文对你有所帮助的话，可以考虑打赏一下本文，用以维持高昂的服务器运营费用（域名费用、服务器费用、CDN费用等）

微信 支付宝

没想到文章加入打赏列表没几天 就有热心网友打赏了 于是国光我用 Bootstrap 重写了一个页面 用以感谢 支持我的朋友，详情请看 打赏列表 | 国光

 Read More