鐵鍋燉本身！寫bug被國家信息安全漏洞共享平臺抓到【後續】

後續來了

以前整理了多篇須要發佈的文章草稿，這篇關於後續的文章一直放在掘金文章草稿箱的底部，致使一直沒有注意到它，直到如今才發佈上來，各位請見諒。

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 技術棧，爲你的技術深度和薪水職位的提高提供充足的保障。

這是一個商城的實戰項目，部分頁面預覽圖以下：

• 首頁

  

• 訂單列表

  

感興趣的朋友能夠關注一下。

除註明轉載/出處外，皆爲做者原創，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文連接，不然保留追究法律責任的權利。

感謝你們的觀看，我是十三，文章首發於個人公衆號「程序員的小故事」。