方案探索過程

隨著CVE-2020-5421的公布，一直使用Spring framwwork老版本的系統(tǒng)突然發(fā)現(xiàn)面臨著窘境乍赫，Spring 開源社區(qū)公布的四個修復(fù)漏洞的版本陆蟆，只是對針對仍在維護(hù)的分支的，在這幾個分支上的版本可以通過順滑升級解決問題改鲫，但對那些已經(jīng)停止維護(hù)的分支比如3.1.x ,3.2.x..則需要使用者自己來解決這個問題林束。而做大幅度跨版本的升級一定會面臨不可盡知的兼容性問題，在緊迫的限期交付補(bǔ)丁包的壓力下缕题，真不知道最終交付的是"安全補(bǔ)丁"還是""連環(huán)雷的引信"胖腾。
自己對在使用的版本進(jìn)行對應(yīng)修改雖然可以用簡單的一句話輕飄飄的來概況：找到對應(yīng)的修改，然后移植到自己用的版本上胸嘁。但每一步的實現(xiàn)，都還需要付出沉重的努力群井。特別是在漏洞被公開后毫胜，負(fù)責(zé)安全的部門也只是根據(jù)公開信息落實責(zé)任，對該漏洞的詳情也僅限于網(wǎng)絡(luò)上的有限知識荐吉，在向這些專業(yè)人士咨詢后也發(fā)現(xiàn)口渔，對該問題只是簡單通報苹威，對再現(xiàn)和驗證連可操作性的說明也沒有，對可見的修改方案就更不要奢望了浮声。在經(jīng)過：忙亂根竿，急躁，沉靜知举，深思后，我們規(guī)避了最激進(jìn)的方案逛钻，以盡量小的修改來解決這個問題遮糖，為此也分成兩個方案叠赐，一個是無跨度，即在當(dāng)前版本(V3.1.1)上進(jìn)行修改赛不；一個是最小跨度罢洲，即找到一個最近版本的較解決完善的版本踢故，在上面做修改, 經(jīng)查看版本更新歷史發(fā)現(xiàn)在v3.2.15上已經(jīng)修復(fù)CVE-2015-5211, 只要再修補(bǔ)CVE-2020-5421即可惹苗，選擇把它作為了這個最接近版本來用。具體的工作情況在下面做了記敘淋纲，以防遺忘院究，也為了給解決類似問題一點參考。

方案一：

構(gòu)建3.1.1

這個工作也不是一帆風(fēng)順伙窃，限于環(huán)境的差異及網(wǎng)絡(luò)的不通暢，也消耗了超出預(yù)料的時間样漆。這個過程在單獨(dú)的過程中做了記錄，參見對Spring framwrok 3.1.1 進(jìn)行構(gòu)建

探索修改內(nèi)容

在構(gòu)建的同時還在通過代碼提交歷史及閱讀代碼定位關(guān)于CVE-2015-5211和CVE-2020-5421兩次修改相關(guān)的提交鳍怨，這個過程也是"拔起蘿卜帶起泥"，本想盡量留用社區(qū)的修改代碼窿冯，但確實版本的變化涉及了功能的增加确徙，而修補(bǔ)又是在功能添加的基礎(chǔ)上的，大有無限蔓延的架勢鄙皇。如果不做取舍也就陷入了泥潭，難免要大動干戈缠沈，看到這個結(jié)果也幾臨崩潰到要放棄错蝴。好在及時的扭轉(zhuǎn)念頭，做了"斷舍離"柬赐，終于將修改內(nèi)容圈定在了閉合的范圍內(nèi)官紫。

修改 CVE-2015-5211

為避免在文中出現(xiàn)太多代碼肛宋，請參見補(bǔ)丁提交記錄Protect against RFD exploits

修改 CVE-2015-5211

請參考補(bǔ)丁提交記錄Avoid unnecessary parsing of path params

形成的的補(bǔ)丁代碼

最終要做的修改在這里已經(jīng)敘述過了CVE-2020-5421 的修復(fù)方法說明束世，本文只側(cè)重整體過程的記敘和總結(jié)，最終結(jié)果在這里了沉帮，可以結(jié)合下文查看和使用代碼補(bǔ)丁文件薪丁。

在修改后提交記錄上生成patch

git format-patch -1 <commitId>

如果要使用該patch, 可以下載patch 文件后可在基于3.1.1.RELEASE 標(biāo)簽建立的分支打上補(bǔ)丁，過程如下

# 基于標(biāo)簽v3.1.1.RELEASE 建立分支
git branch v3.1.1.clone v3.1.1.RELEASE

# 切換分支
git checkout v3.1.1.clone

# 在新建分支上打上補(bǔ)丁
git apply <patchfile>

# 構(gòu)建或繼續(xù)進(jìn)行修改
...

方案二

這個方案里粱檀，最擔(dān)心的是版本的兼容性問題漫玄，在未做任何修改的情況下把升級為3.2.15進(jìn)行測試压彭，果然很快遇到了問題渗常。因為我們對spring框架做過擴(kuò)展，對rest的相關(guān)的json序列化進(jìn)行過處理询一，而3.2.x和3.1.x在對http 消息轉(zhuǎn)換的處理上 存在差別，導(dǎo)致出現(xiàn)了異常健蕊。雖然定位到了問題踢俄，但是否還有類似問題？是否能在非常有限時間里發(fā)現(xiàn)和解決都办，這顯然是有很大的不確定性。

隨想

隨著方案一的修改的完成琳钉，最終選用了的方案一作為本次補(bǔ)丁的應(yīng)對之策。但這應(yīng)該認(rèn)識到這只限于對本次的問題在有限的時間內(nèi)應(yīng)對是最優(yōu)的方法槽卫，并不是系統(tǒng)性的最優(yōu)胰蝠，出現(xiàn)開始描述的窘境的原因是因為日積月累欠下的"技術(shù)債"，既然系統(tǒng)還在生命周期內(nèi)躲庄，尚未有明確的下線日期钾虐，為避免這樣的窘境噪窘，就應(yīng)該在日常的工作中有組件升級的安排效扫。這正如對你的愛車的保養(yǎng)，做保養(yǎng)時看似多余浩习，但如果從不做養(yǎng)護(hù)济丘，到問題發(fā)生時可能的后果就是你不能承受的洽蛀。

回頭看時疟赊，都是很簡單的事情郊供，直接按照以上步驟進(jìn)行修改近哟，可能在兩個小時內(nèi)就能完成吉执。但正如軟件生產(chǎn)的成本和傳播成本的差異，復(fù)制粘貼很快就能完成鼠证，走直路也永遠(yuǎn)都是快樂的，但如果你未經(jīng)過對問題的一頭霧水适掰，對多個方案的思考和對比荠列，對每個步驟的不確定性的體驗，你不會知道费就，所謂的直路都是經(jīng)歷過的人給你做過路標(biāo)才是可能有的川队。

假如類似問題再次來臨，還是要遵守事情的規(guī)律眠蚂，做到不急不燥斗躏，同時大膽心細(xì)，在對問題做深入分析的基礎(chǔ)上完成修改笛臣，且對形成問題的復(fù)現(xiàn)及檢測的有效方法要充分重視隧饼，這是開發(fā)方與安全檢測方必須達(dá)成一致后才能關(guān)閉問題的核心點。

當(dāng)然踱蛀，作為重點最后重復(fù)一遍：從長久來看，及時的技術(shù)升級是避免出現(xiàn)窘境的根本崩泡，特別是對于對技術(shù)進(jìn)行集中管控的組織猬膨，業(yè)務(wù)應(yīng)用開發(fā)者使用了組織內(nèi)定制和擴(kuò)展后的開源組件，集中管控方要主動推動業(yè)務(wù)項目組的組件升級勃痴，這也是集中管控的重要作用沛申。

[前一篇]CVE-2020-5421 的修復(fù)方法說明
[后一篇]對Spring framwrok 3.1.1 進(jìn)行構(gòu)建