后续来了
之前整理了多篇需要发布的文章草稿，这篇关于后续的文章一直放在掘金文章草稿箱的底部，导致一直没有注意到它，直到现在才发布上来，各位请见谅。
2019 年 12 月 16 日早上八点半，我在掘金上发布了来到这个平台的第一篇文章《捅娄子了，写个bug被国家信息安全漏洞共享平台抓到了？》，文章主要讲述了一下自己在开源项目 newbee-mall 中的一个 bug 被国家信息安全漏洞共享平台 CNVD 和国际安全漏洞库 CVE 收录的事件。可能是文章写得很逗吧，大家也觉得有意思，所以阅读量还算不错：
8 点半发布，3 小时后再去看已经有 4K 的阅读量了，看到这里我真的是诚惶诚恐，虽然已经写了几年的文章，但是对于掘金来说，我还是一个新人，所以特别感谢大家的支持！
本来觉得那篇文章已经把整个事件讲完了，但是有朋友在文章下面留言，也有朋友在群里给我发消息，让我做一点小小的扩展，因此又动笔写了这篇文章，讲讲后续的事情以及朋友们问到的几个问题，但是草稿箱里的文章太多了，导致忽略了这一篇，本来是应该在去年年底发的，搞到现在 3 月底才发上来，尴尬。
我的梦想就是有一个自己的 CVE 编号
文章发出之后呢，也有朋友留言称 “我的梦想就是有一个自己的 CVE 编号”，下面还有朋友附和：
看到这里呢，我是有些蒙了，咱也不知道咋回事儿，咱也不敢问。
虽然我经历过 CVE 和 CNVD 这次事件，但是我对于 CVE 还是有些陌生的，所以看到上面这个对话呢，我也不知道真的假的，总感觉他们在逗我玩儿。
当然，不懂嘛，就去学习，看到上面的这个对话，我有个想法就是：“CVE 编号是有一定价值的”，但是我对于这个东西可以说是一无所知，因此我觉得这应该不是开发者圈子里的事情，更像是网络安全圈的术语和事情，之后我又在空闲的时间去查了一些 CVE 的资料。
我所理解的 CVE
由于并不是特别了解，我只是简单的谈一下自己的想法，如有不当之处还望见谅。
什么是 CVE
CVE 的全称是 “Common Vulnerabilities and Exposures” ，翻译成中文就是“公共漏洞和披露”，我们可以把它理解成一个被安全从业者认可的漏洞字典，划重点，安全从业者，这个东西确实不是开发者圈内的事情，所以感觉陌生也是正常的，大家可以通过 CVE 编号在 CVE 官网查找不同应用或系统的漏洞信息，很多安全企业或国家机构也都会引用 CVE 作为其漏洞库，比如前文中提到的 CNVD 即为我们国内的漏洞数据库。
CVE 编号是有价值的
说完了 CVE，咱们接着来说一下 CVE 编号的价值，以下内容主要是通过网上的一些内容整理出来的。
首先，提交了 CVE 漏洞是有可能直接获得奖金的，但是不同的组织或许会有不同的漏洞奖励计划，不同的漏洞肯定奖励级别也不一样，如果你提交了很有价值的信息，很有可能获得一笔奖金。其次，即使无法直接获得奖金，你也可以通过提交 CVE 漏洞来获得一些有价值的 CVE 编号，这些内容可以放到简历里，也可以作为找工作的加分项，比如我们开发人员运营的 GitHub 仓库或者博客文章，也可以放在我们求职简历里作为加分项。
以上是我对于 CVE 编号价值粗浅的认识，可能还有其他更大的价值，但是我不太了解，因此不再继续献丑了。
其他
CVE 编号的获取是需要去主动申请的，就像是申请一个账号一样，总之，去对应的网站填写表格即可，之后就是漏洞的审核、漏洞的公开等等步骤，如果一切顺利并且漏洞是真实存在的，就可以获得一个 CVE 编号啦。
还有，获得 CVE 编号并不等于这个漏洞是有价值的，甚至说这个漏洞都不一定是真实存在的，比如前文中提到的 newbee-mall 项目的 SQL 注入漏洞，漏洞虽然是真实存在的，但是影响面不会特别大，没有影响到网络安全，个人觉得这个 CVE 编号的价值并不大，倒是这次乌龙事件把我吓得不轻。
SQL 注入问题解决
这里也有朋友问到了这次 bug 的解决过程，这里我也来解释一下，这个 bug 其实是一个比较简单的原因导致的，就是在 Mapper 文件中传参时我使用了 ${} 方式，这种方式也能够正确的解析参数和执行 SQL 语句，但是会存在 SQL 注入的风险，所以需要处理掉，解决的方式就是改为 #{} 进行参数解析。
#{paramentName} 是预编译处理，MyBatis 框架在处理 #{} 时会将 SQL 语句中的 #{} 解析为一个参数占位符，然后调用 PreparedStatement 的 set 方法来赋值，传入字符串后，会在值两边加上单引号，比如传入的 keyword 参数值为 电脑 ，在拼接到 SQL 语句中时会变成 '电脑'。
${paramentName} 是字符串替换， MyBatis 框架在处在处理 ${} 时会将 SQL 语句中的 ${} 替换为变量的值，传入的参数值不会加两边加上单引号，比如传入的 keyword 参数值为 电脑 ，在拼接到 SQL 语句中时依然是 电脑。
所以使用 ${} 方式会导致 SQL 注入问题，不利于系统的安全性，因为这种方式是直接替换，传进来什么值就会拼接什么值，如果有一些 SQL 关键字被恶意拼接进来可能导致一些不可挽回的损失，而使用 #{} 方式的话，不管传进来什么，都会被解析为一个字符串。
这个知识点也不是特别麻烦，想要了解更多的话，你可以查一下“Mybatis中$与#的区别”。
永不缺席的广告党
这个广告，在这篇文章里出现了 N 多次，心累。
我这真的是捅了猴子窝了。
每次都会找管理员帮忙清理一波，真的是辛苦各位了。
写在最后
做个小推广，感兴趣的朋友可以看一看，最近我在掘金平台上发布了一本小册《Spring Boot 大型线上商城项目实战教程》（点击该链接或者点击下方图片购买可以优惠 8 折哦）：
小册将围绕 Spring Boot 技术栈，使用的其它技术框架也会兼顾最新技术动向，对知识进行拓展，由浅入深，步步为营，在学习基础的同时也能够掌握一定的开发技巧，不仅仅只是学习 Spring Boot 的皮毛，也知晓它的源码设计和内部原理，不仅仅只是学习 Spring Boot 的相关技术栈整合，也能够使用 Spring Boot 技术栈搭建一个大型的商城系统，从而让你拥有一个高质量的学习进阶体验。远离 Hello World 项目，让你既能够得到一份完整的实操项目，也能够帮你点满目前炽手可热的 Spring Boot 技术栈，为你的技术深度和薪水职位的提升提供充足的保障。
这是一个商城的实战项目，部分页面预览图如下：
感兴趣的朋友可以关注一下。
除注明转载/出处外，皆为作者原创，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。
感谢大家的观看，我是十三，文章首发于我的公众号“程序员的小故事”。
