1
後續來了
之前整理了多篇需要發佈的文章草稿，這篇關於後續的文章一直放在掘金文章草稿箱的底部，導致一直沒有注意到它，直到現在才發佈上來，各位請見諒。
2019 年 12 月 16 日早上八點半，我在掘金上發佈了來到這個平臺的第一篇文章《捅婁子了，寫個bug被國家信息安全漏洞共享平臺抓到了？》，文章主要講述了一下自己在開源項目 newbee-mall 中的一個 bug 被國家信息安全漏洞共享平臺 CNVD 和國際安全漏洞庫 CVE 收錄的事件。可能是文章寫得很逗吧，大家也覺得有意思，所以閱讀量還算不錯：
8 點半發佈，3 小時後再去看已經有 4K 的閱讀量了，看到這裏我真的是誠惶誠恐，雖然已經寫了幾年的文章，但是對於掘金來說，我還是一個新人，所以特別感謝大家的支持！
本來覺得那篇文章已經把整個事件講完了，但是有朋友在文章下面留言，也有朋友在羣裏給我發消息，讓我做一點小小的擴展，因此又動筆寫了這篇文章，講講後續的事情以及朋友們問到的幾個問題，但是草稿箱裏的文章太多了，導致忽略了這一篇，本來是應該在去年年底發的，搞到現在 3 月底才發上來，尷尬。
2
有一個自己的 CVE 編號
文章發出之後呢，也有朋友留言稱 “我的夢想就是有一個自己的 CVE 編號”，下面還有朋友附和：
看到這裏呢，我是有些蒙了，咱也不知道咋回事兒，咱也不敢問。
雖然我經歷過 CVE 和 CNVD 這次事件，但是我對於 CVE 還是有些陌生的，所以看到上面這個對話呢，我也不知道真的假的，總感覺他們在逗我玩兒。
當然，不懂嘛，就去學習，看到上面的這個對話，我有個想法就是：“CVE 編號是有一定價值的”，但是我對於這個東西可以說是一無所知，因此我覺得這應該不是開發者圈子裏的事情，更像是網絡安全圈的術語和事情，之後我又在空閒的時間去查了一些 CVE 的資料。
3
我所理解的 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 編號的價值並不大，倒是這次烏龍事件把我嚇得不輕。
4
SQL 注入問題解決
這裏也有朋友問到了這次 bug 的解決過程，這裏我也來解釋一下，這個 bug 其實是一個比較簡單的原因導致的，就是在 Mapper 文件中傳參時我使用了 ${} 方式，這種方式也能夠正確的解析參數和執行 SQL 語句，但是會存在 SQL 注入的風險，所以需要處理掉，解決的方式就是改爲 #{} 進行參數解析。
#{paramentName} 是預編譯處理，MyBatis 框架在處理 #{} 時會將 SQL 語句中的 #{} 解析爲一個參數佔位符，然後調用 PreparedStatement 的 set 方法來賦值，傳入字符串後，會在值兩邊加上單引號，比如傳入的 keyword 參數值爲 電腦 ，在拼接到 SQL 語句中時會變成 '電腦'。
${paramentName} 是字符串替換， MyBatis 框架在處在處理 ${} 時會將 SQL 語句中的 ${} 替換爲變量的值，傳入的參數值不會加兩邊加上單引號，比如傳入的 keyword 參數值爲 電腦 ，在拼接到 SQL 語句中時依然是 電腦。
所以使用 ${} 方式會導致 SQL 注入問題，不利於系統的安全性，因爲這種方式是直接替換，傳進來什麼值就會拼接什麼值，如果有一些 SQL 關鍵字被惡意拼接進來可能導致一些不可挽回的損失，而使用 #{} 方式的話，不管傳進來什麼，都會被解析爲一個字符串。
這個知識點也不是特別麻煩，想要了解更多的話，你可以查一下“Mybatis中$與#的區別”。
5
永不缺席的廣告黨
這個廣告，在這篇文章裏出現了 N 多次，心累。
我這真的是捅了猴子窩了。
每次都會找管理員幫忙清理一波，真的是辛苦各位了。
6
寫在最後
做個小推廣，感興趣的朋友可以看一看，最近我在掘金平臺上發佈了一本小冊《Spring Boot 大型線上商城項目實戰教程》（長按下方二維碼或者點擊“閱讀原文”進行購買可以優惠 8 折哦）：
小冊將圍繞 Spring Boot 技術棧，使用的其它技術框架也會兼顧最新技術動向，對知識進行拓展，由淺入深，步步爲營，在學習基礎的同時也能夠掌握一定的開發技巧，不僅僅只是學習 Spring Boot 的皮毛，也知曉它的源碼設計和內部原理，不僅僅只是學習 Spring Boot 的相關技術棧整合，也能夠使用 Spring Boot 技術棧搭建一個大型的商城系統，從而讓你擁有一個高質量的學習進階體驗。遠離 Hello World 項目，讓你既能夠得到一份完整的實操項目，也能夠幫你點滿目前熾手可熱的 Spring Boot 技術棧，爲你的技術深度和薪水職位的提升提供充足的保障。
這是一個商城的實戰項目，部分頁面預覽圖如下：
首頁
訂單列表
感興趣的朋友可以關注一下。
“程序員的小故事”公衆號中除註明轉載/出處外，皆爲作者原創，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，否則保留追究法律責任的權利。
