後續來了
之前整理了多篇需要釋出的文章草稿，這篇關於後續的文章一直放在掘金文章草稿箱的底部，導致一直沒有注意到它，直到現在才釋出上來，各位請見諒。
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 技術棧，為你的技術深度和薪水職位的提升提供充足的保障。
這是一個商城的實戰專案，部分頁面預覽圖如下：
感興趣的朋友可以關注一下。
除註明轉載/出處外，皆為作者原創，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結，否則保留追究法律責任的權利。
感謝大家的觀看，我是十三，文章首發於我的公眾號“程式設計師的小故事”。
