背景

我想作為一個信息安全從業(yè)者，無論是在滲透測試、代碼審計亦或是其他安全服務(wù)中都會接觸到各種各樣的漏洞。把這些漏洞進行簡單分類可能能夠得到幾十類漏洞，當(dāng)然幾乎所有的漏洞類型在common Weakniss Enumeration都有相應(yīng)的描述。

面對類型如此豐富漏洞，我們要如何進行處理呢?

要知道人類的本質(zhì)是懶惰，逐條進行分析驗證幾乎是不可能的。而且滲透測試、紅藍對抗等服務(wù)在本質(zhì)上都是為了達到以點帶面的目的，那么這個面在哪里是值得我們?nèi)ニ伎嫉膯栴}。

廢話扯完了，進入正題。

安全策略清單

本文所說的安全策略，即系統(tǒng)采用的方式用于處理可能存在的安全風(fēng)險。

我這邊簡單的梳理了一下，在考慮軟件安全時需要考慮的幾個方面的問題，圖如下：

身份認(rèn)證策略、訪問控制策略、會話管理策略這三個方面基本上屬于整個軟件安全的基石，如果這三個方面缺少了相應(yīng)控制或者實現(xiàn)的大方向上存在問題，那么對于整個軟件的影響極大，可能是顛覆性的需要推到重建。

• 對抗中間人： 對于中間人攻擊大部分人的看法可能是屬于軟件后期的部署問題，采用https/HSTS就沒什么問題(問題可能并沒有這么簡單)，不過我還是把它納入到框架。
• 輸入輸出： 這可能有點老生常談，不過我覺得清楚的了解對于軟件而言什么是輸入，什么是輸出，可能會更好進行分析。
• 敏感數(shù)據(jù)：在網(wǎng)絡(luò)逐漸形成虛擬社會的背景下，其開放性的特征必然會引起有關(guān)部門的注意，作為一項重要的合規(guī)項應(yīng)當(dāng)在初期就納入考慮到。同時如果出現(xiàn)相應(yīng)的問題，軟件修復(fù)起來極其頭疼，完全可能出現(xiàn)修不完的情況，在投產(chǎn)的過程觸犯了相應(yīng)的法規(guī)造成的損失可能也極其巨大。
• 軟件技術(shù)棧： 白話一點的說法就是軟件都用了什么技術(shù)。
• 配置管理： 一些意料之外漏洞可能都出自于錯誤的配置管理，諸如交易日志泄露
• 異常處理： 安全對抗的本質(zhì)是獲取信息，盡可能的獲取一些常規(guī)獲取不到的信息，異常是一項比較重要的來源。

一、身份認(rèn)證

1. 概念

在虛擬世界中的身份認(rèn)證同現(xiàn)實世界中一樣，首先需要識別人，建立在識別的基礎(chǔ)能夠去開展各項業(yè)務(wù)，產(chǎn)生、處理、使用、存儲數(shù)據(jù)。 只是目前而言，由于你是真實存在的，不會出現(xiàn)類似于證明你是你問題，而虛擬身份的更像是一個物化的概念，那么身份認(rèn)證就是能夠證明虛擬身份是屬于現(xiàn)實的你。

所以在虛擬世界這是一個必須要解決的問題——如何讓真實的你與虛擬世界中虛擬的你進行綁定。

那么最直接的方式就是提供秘密——只有賬號的擁有者持有的信息。例如在賬號注冊時輸入的密碼信息、密保信息

換句話說，在虛擬的世界中只要能夠提供賬號的相關(guān)的秘密信息，就能聲明賬號的所有權(quán)。因為對于全知全能的程序而言，它都是僅僅收到了這個秘密，你和他并沒有區(qū)別。

舉個例子：

• alkaid登錄賬號alkaid，輸入了密碼password，程序驗證通過，允許以alkaid賬號執(zhí)行相關(guān)業(yè)務(wù)
• person2 不知道通過什么途徑知道了，alkaid/password的認(rèn)證信息，程序驗證通過，允許以alkaid賬號執(zhí)行相關(guān)業(yè)務(wù)。

2. 風(fēng)險與處理

現(xiàn)在身份認(rèn)證應(yīng)該就是很清晰了，其實就是驗證虛擬賬號的秘密信息，那么要知道只要是驗證信息就會返回成功和失敗的結(jié)果，從一定程度這也是一類信息泄露，只是信息泄露的量較少，通過不斷累積信息，就能最終破獲秘密信息，也是身份認(rèn)證主要的風(fēng)險點。

這類風(fēng)險的直接體現(xiàn)就是暴力枚舉破解賬號。

當(dāng)然，這風(fēng)險屬于無法解決的，我們只能采用降低風(fēng)險，使風(fēng)險可控的方式：

解決累積信息的特點：

• 賬號鎖定機制

由于完美解決1是相對困難的(主要是引入的不可用風(fēng)險不一定能被接受)，也可以采用提高目標(biāo)的信息量的方式，在有限的時間維度內(nèi)，無法破解賬號：

• 提供秘密信息的復(fù)雜度，例如密碼的復(fù)雜度
• 采用驗證碼技術(shù)，防止通過機器突破現(xiàn)實人的極限

減少單次信息累積的量：

• 模糊失敗的錯誤提示

其實還有其他的無法解決的風(fēng)險，例如秘密信息被竊取。所以一般還會要求提供更換秘密信息的功能：

• 采用生物信息的技術(shù)讓人難以接受的是無法進行更新秘密信息，如果需要更換可能需要重新設(shè)計相關(guān)的算法和信息采樣的算法，可能會要求所有虛擬用戶同時更換設(shè)備和秘密信息。

二、會話管理

1. 概念

由于HTTP協(xié)議屬于無狀態(tài)(每個數(shù)據(jù)包都是獨立的，僅根據(jù)數(shù)據(jù)包無法判斷之前發(fā)過哪些數(shù)據(jù)包)的協(xié)議，同時在身份認(rèn)證一節(jié)中已經(jīng)說明大部分的業(yè)務(wù)操作是需要基于虛擬身份進行的，那么在完成身份認(rèn)證后，后續(xù)數(shù)據(jù)包無法回溯之前的數(shù)據(jù)包，從而導(dǎo)致無法證明自己確實能夠持有聲明的虛擬身份。

當(dāng)然如果每次都帶著身份的秘密信息請求進行確實是可以進行身份認(rèn)證，但是頻繁的使用這類秘密信息可能會增加秘密信息泄露的風(fēng)險。

現(xiàn)實的生活中由于時間和空間的限制，基本上不存在這類風(fēng)險，我們也很難進行參考。

不過這類問題反過來——如何讓服務(wù)器知曉是你這個真實的人在操作你的擁有的虛擬身份(問題又回到了身份認(rèn)證)

• 同身份認(rèn)證一章節(jié)所述，那就是掌握秘密信息。
• 即服務(wù)器與我商量一個只有我們兩個人知道的臨時秘密，來替代原先虛擬身份的秘密。
• 臨時秘密作為虛擬身份的秘密的替代品，在每次訪問時都進行提供。—— 臨時秘密即我們一般而言的sesssionID(會話ID)。

會話管理，即圍繞sessionID是怎么進行處理的。

再繞一點，是不是覺得會話像是系統(tǒng)給我開設(shè)的臨時虛擬身份，但是同時具有原先虛擬身份的信息?

確實沒錯，會話從某種程度上來講與賬號其實沒有區(qū)別，也能夠提供相應(yīng)的信息存儲，只不過會話是臨時的。

2. 風(fēng)險與處理

會話與賬號相似，其面對的風(fēng)險也與身份認(rèn)證相同。

但是由于是相似(如果完全相同，又會回到最開始的問題——無法證明自己確實能夠持有聲明的虛擬身份)，會話最大的一個特征是臨時性。 由于預(yù)置的時間屬性，基本我們采用2中的復(fù)雜度方式。

如何來盡可能的保證的復(fù)雜度呢?

隨機生成的符號組合。(避免組合單詞，賬號信息等，從信息熵的角度來說，盡可能避免與已知信息相關(guān)聯(lián)，關(guān)聯(lián)的越多，這段數(shù)據(jù)包含的信息越少，越容易被猜測)

一定長度的保證(每一位的長度增加，破解難度都是成倍提高)

三、訪問控制

1. 概念

鑒于可能會與我們學(xué)習(xí)過的MAC、DAC、RBAC混淆，這節(jié)討論的東西不是這些具體的策略，談?wù)撨@些具體的策略，可能搜索一下google、wiki來得更加方便和準(zhǔn)確,是討論訪問控制解決什么問題，面對什么樣的風(fēng)險。

涉及到訪問控制，自然有兩個概念，主體和客體。

2. 主體

一般指提出訪問請求的對象。在實現(xiàn)身份認(rèn)證和會話管理的基礎(chǔ)上，主體相對明確，有兩類構(gòu)成

• 虛擬身份代表的主體
• 沒有虛擬身份，(代表了所有未授權(quán)的情況)

3. 客體

一般指被訪問的資源。 具體哪些資源其實在相關(guān)的系統(tǒng)里是很難明確的，這里我僅提及兩類，功能和數(shù)據(jù)。 它們應(yīng)該是在各類系統(tǒng)中最最常見的兩類資源。

4. 分析

既然是虛擬時間，如果排除了空間和時間的影響，其本質(zhì)應(yīng)該是一樣的，現(xiàn)實中與安全性質(zhì)類似場景包括消防、防盜、安保等

這里以我居住的小區(qū)為例，alkaid 住在A小區(qū)1幢11層1111房間。

我需要回到我的房間需要經(jīng)過，小區(qū)的門禁、1幢的門禁、1幢的電梯梯控、1111房間的鑰匙、密碼。

我們講現(xiàn)實的場景與虛擬的場景進行映射，幫助進行分析也方便大家思考，發(fā)現(xiàn)一些我可能沒有提到的東西。

小區(qū)的門禁，相當(dāng)于系統(tǒng)的身份認(rèn)證，通過門禁確認(rèn)我屬于小區(qū)的住戶

進入小區(qū)后，處于會話管理的范疇內(nèi)，當(dāng)我只持有1幢的門禁和梯控，相當(dāng)于只允許我訪問某些功能。

而房間鑰匙則對應(yīng)著我的數(shù)據(jù)訪問權(quán)限。

而小區(qū)的跑道和綠化則屬于授權(quán)用戶的公共資源， 小區(qū)外的其他則屬于任何人都能訪問的資源

小區(qū)中遍布的監(jiān)控能夠支持對行為的審計

5. 總結(jié)

在訪問控制方面，我們至少需要幾點：

• 功能級別訪問控制
• 針對用戶數(shù)據(jù)或者其他資源的數(shù)據(jù)級的訪問控制
• 梳理公共資源以及個人的資源
• 監(jiān)控與審計

6. 風(fēng)險與處理

風(fēng)險也圍繞著我們在上文所說的幾點相關(guān)資源的訪問控制(即門禁的設(shè)計)。

根據(jù)系統(tǒng)不同的需要，對不同的資源設(shè)置相應(yīng)的訪問權(quán)限。畢竟在一般情況下，我房間應(yīng)該只有我以及我授權(quán)的相關(guān)人員能夠進入：

• 需要評估和確認(rèn)訪問權(quán)限設(shè)計的有效性，滿足最小化的原則
• 對于資源默認(rèn)的訪問權(quán)限應(yīng)當(dāng)是拒絕
• 授權(quán)繞過/未授權(quán)訪問
• 在系統(tǒng)變更過程中是否持續(xù)對資源進行梳理和監(jiān)控
• 側(cè)信道/信息推測

例子的描述： 房間里會有窗戶，可能透過窗戶能夠看到一些 或者 分析你的生活習(xí)慣推測一些信息。 從描述來看，風(fēng)險相較于其他幾項較少。

之前提到過，我們忽略了時間和空間的影響。在虛擬世界中可能會存在直接訪問到我個人房間的情況，所以一般情況下我們首先需要去驗證訪問者是否持有認(rèn)證通過后持有的虛擬身份。(一般這個操作在軟件系統(tǒng)中會作為全局?jǐn)r截器來實現(xiàn)，相當(dāng)于將所有的資源納入到門禁的范圍內(nèi)，避免在實現(xiàn)新增功能時，忘了考慮這類情況，從而產(chǎn)生風(fēng)險【該類情況即使通過審計發(fā)現(xiàn)，也無法進行追溯】。)

四、對抗中間人

1. 背景

在前文中提到的三大基石策略——身份認(rèn)證、訪問控制和會話管理，在通信過程都涉及到與遠(yuǎn)程服務(wù)器交換秘密信息，同時在實際的業(yè)務(wù)過程中，也包含了大量的個人隱私信息。

如果這些信息被竊取，可能會對社會、個人造成巨大的影響。

2. 概念

在具體討論怎么對抗中間人之前，我們首先來看看中間人到底是什么?

從名字來看，中間——那肯定是在什么之間。

信息系統(tǒng)常見幾個重要的主體，應(yīng)用、操作系統(tǒng)、網(wǎng)絡(luò)鏈路、客戶端、服務(wù)端，通信過程如下：

一般而言，我們所考慮的中間人攻擊的情況是圖中虛線的框框——網(wǎng)絡(luò)設(shè)備，攻擊者可能控制了相關(guān)的路由器或者交換機，進而對應(yīng)用的相關(guān)數(shù)據(jù)包進行監(jiān)聽、篡改。

一般不考慮應(yīng)用與操作系統(tǒng)、操作系統(tǒng)與網(wǎng)卡之間攔截，一方面由于這些操作都需要對客戶端/服務(wù)端的操作系統(tǒng)進行控制，如果能進行控制，那么有其他更加豐富的方式獲 取相關(guān)的數(shù)據(jù)，包括但不僅限于hook相關(guān)的技術(shù)、屏幕錄像。 另一方面，由于需要獲取操作系統(tǒng)的控制權(quán)，一般而言是個例，不具有普遍性，在資源有限的情況，不會進行考慮。同時在這類場景下，更關(guān)鍵是需要解決惡意攻擊者獲得操作系統(tǒng)控制權(quán)的問題。

當(dāng)然，如果有特殊的要求確實需要納入到考慮范圍的情況，那肯定需要在應(yīng)用層面去完成，自然是最方便的途徑，從數(shù)據(jù)的源頭進行防護，設(shè)計的要求同針對網(wǎng)絡(luò)設(shè)備的中間人一致。

對抗中間人攻擊，不可能去解決掉中間人，而不可能去保證每個人一個人的鏈路的安全。

需要解決如何在不可性的鏈路上去構(gòu)建一個可信或者相對可信的鏈路。

3. 風(fēng)險與處理

風(fēng)險其實在背景里已經(jīng)提到了就是信息被竊取、篡改，而處理的解決方式就是需要去構(gòu)建可信信道。

具體的風(fēng)險可以細(xì)化成以下四種：

• 虛擬身份或者臨時身份被竊取
• 重放
• 監(jiān)聽(隱私信息采集等)
• 業(yè)務(wù)數(shù)據(jù)包被篡改

從風(fēng)險可知，構(gòu)建的可信信道需要滿足數(shù)據(jù)被加密，防止被竊取身份，被采集信息加密應(yīng)該保證每個對象與對象之間不同(如果是現(xiàn)代密碼學(xué)算法應(yīng)該保證每組通信采用不同的密鑰)。

• 需要支持完整性的校驗
• 需要支持對抗重放數(shù)據(jù)——即每個數(shù)據(jù)包有自己的標(biāo)識

4. 已有技術(shù)

提到中間人，不得不提到的一定是SSL、TLS，以及結(jié)合http協(xié)議形成的https，一般情況其代碼實現(xiàn)已經(jīng)集成在操作系統(tǒng)中。

理想情況下，TLS或者SSL協(xié)議能夠達成我們的目標(biāo)，但是它們在構(gòu)建可信信道的過程中，依賴于數(shù)字證書技術(shù)。如果不當(dāng)使用數(shù)字證書，例如自簽證書、不可信CA濫發(fā)證書，那么可信信道就無法構(gòu)建。

無共享信息的可信信道，基本上無法建立，除了量子。

那么為了部分解決SSL/TLS的數(shù)字證書問題，只能采取增加部分預(yù)置信息的方式，例如HSTS——瀏覽器緩存證書，SSL Pinning——內(nèi)置證書進行比較

5. 注意事項

由于SSL/TLS是對抗中間人的完整性校驗和對抗重放，重放的另一個威脅源來自客戶端自身在應(yīng)用層發(fā)起的請求，這類情況無法適用SSL/TLS。

一般建議在應(yīng)用層面的核心業(yè)務(wù)，再次實現(xiàn)完整性校驗和對抗重放的技術(shù)。例如交易。

五、異常處理

滲透測試的小伙伴應(yīng)該會這樣的體會——只有當(dāng)輸入信息與我們預(yù)期的正常情況存在出入的時候，才會引起注意，例如頁面500報錯、異常的業(yè)務(wù)流程、預(yù)計之外數(shù)據(jù)輸出。

所以異?？梢运闶且磺泄舻脑搭^，如果所有的情況都能符合預(yù)期，那么我想攻擊者的途徑應(yīng)該會少很多吧。

可惜的是人非圣賢，異常難以避免。

對研發(fā)而言，我們希望異常越清晰越好，查看異常越簡單越好，能夠協(xié)助我們盡快的定位bug，分析業(yè)務(wù)。

在攻擊者在挖掘漏洞的過程，同樣希望異常越清晰越好，與開發(fā)者們的預(yù)期一致，在頻繁的上線和更新代碼的過程中，經(jīng)常會遺忘掉這些暗門，從而使攻擊者能夠從研發(fā)留下的痕跡中收獲不少敏感信息。

所幸的是目前部分框架已經(jīng)支持對全局異常的統(tǒng)一處理。

剩下的需要解決的是配置問題，在下文中也會單獨的講這個問題，不過在這個篇章里索性就先提一點。

研發(fā)人員和攻擊者都關(guān)注異常信息，自然不可能把異常信息全都屏蔽，那么對于研發(fā)人員可能是一場災(zāi)難。

那么如何把兩者劃開來呢，測試環(huán)境自不必說，對于生產(chǎn)環(huán)境而言，攻擊者能接觸到的應(yīng)用頁面、通信的數(shù)據(jù)包，而研發(fā)人員在授權(quán)的情況下，理論上可以接觸到所有數(shù)據(jù)的，所以我們可控制異常信息的輸出，輸出到攻擊者無法接觸的地方，例如操作系統(tǒng)的某個固定目錄下、統(tǒng)一的日志收集平臺。

當(dāng)然有個后話，如何保證相關(guān)目錄的安全、日志平臺安全以及哪些數(shù)據(jù)需要隱藏又是我們需要繼續(xù)考慮的問題。

注意事項：

異常處理的手段其實在本質(zhì)上并不能解決信息泄露的問題，只是通過對異常處理的控制，盡可能地降低從異常中獲取的信息量，提高攻擊者的攻擊成本和利用難度，從而降低風(fēng)險。

(沒有任何回顯，本身就是一種異常。只是造成這類異常的情況豐富且復(fù)雜，從而降低從異常中獲取得信息量)

PS：信息量/信息熵等概念，可自行搜索了解，本質(zhì)上是為了量化信息。

六、配置管理

對于應(yīng)用系統(tǒng)而言，經(jīng)常需要部署在不同的運行環(huán)境，我們引入了配置從而避免了因為環(huán)境的變動就需要對應(yīng)用進行重新編碼，重新測試的情況，同時各種各樣的配置項可以支持各式各樣的組件和程序不同的運行方式，極大的提高了效率。

1. 場景一 不同的運行環(huán)境

跨平臺的編程語言解決了應(yīng)用需要在不同操作系統(tǒng)部署的問題，優(yōu)化了大量的時間投入。但是它們沒辦法解決不同抽象的運行環(huán)境，例如開發(fā)環(huán)境、測試環(huán)境、準(zhǔn)生產(chǎn)、生產(chǎn)環(huán)境，不同的抽象運行環(huán)境對應(yīng)著不同的組件、網(wǎng)絡(luò)以及信息安全的要求。

• 開發(fā)環(huán)境/測試環(huán)境：對于信息安全的要求應(yīng)該是最低，同時也是輸出信息最為豐富、系統(tǒng)最不穩(wěn)定的。
• 準(zhǔn)生產(chǎn)/生產(chǎn)環(huán)境：對于信息安全有明確的要求，僅保留必要的輸出，系統(tǒng)最為穩(wěn)定。

2. 風(fēng)險與處理

在從開發(fā)環(huán)境切換到準(zhǔn)生產(chǎn)/生產(chǎn)環(huán)境，難免需要更新具體的配置，一般而言會考慮引入編譯的配置選項來解決，實現(xiàn)一鍵切換，例如maven的profile屬性，不同的屬性值對應(yīng)了不同的策略，包括不同的打包策略、不同的配置文件。

這類方式是提高系統(tǒng)可靠性的重要方式，但是也存在一些副作用，需要使用者進行控制。

如果管理不當(dāng)，開發(fā)者有可能接觸到生產(chǎn)環(huán)境的具體配置信息，對生產(chǎn)經(jīng)營產(chǎn)生影響

如果打包策略/配置文件未進行檢查和校驗，導(dǎo)致多個環(huán)境信息被一起打包。

如果缺少對具體配置項的檢查，導(dǎo)致生產(chǎn)環(huán)境采用了測試環(huán)境的配置，進而可能產(chǎn)生信息泄露事件。

各個組件(中間件、容器等)的配置。雖然目前有docker一類的容器技術(shù)，用于實現(xiàn)運行環(huán)境的標(biāo)準(zhǔn)化配置，但是標(biāo)準(zhǔn)化配置不是一個不再需要關(guān)注的點而是一個更加需要關(guān)注的點，試想如果某個標(biāo)準(zhǔn)化上配置存在弱口令賬號或者所有的標(biāo)準(zhǔn)化環(huán)境共享一個賬號，會帶來什么樣的風(fēng)險。

3. 場景二 日志管理

日志功能相關(guān)的組件越來越成熟，大多通過配置進行實現(xiàn)，索性就納入到了配置管理模塊。

日志是目前所有系統(tǒng)審計的重要依據(jù)，同時也是發(fā)現(xiàn)攻擊者和內(nèi)鬼的重要手段，但是隨著SSL/TLS等相關(guān)加密方式普及，位于通信鏈路上的相關(guān)設(shè)備越來越難以捕獲到明文信息，應(yīng)用系統(tǒng)自身的日志顯得越來越重要。 我想隨著云相關(guān)技術(shù)的進一步推廣，應(yīng)用系統(tǒng)的日志會更加重要。

如何管理這些日志，采集哪些日志就是需要進行考慮的。

4. 風(fēng)險與處理

日志最好也能有全局的日志控制。

當(dāng)然，如果需要最大發(fā)揮日志的價值，一般是需要匯集到統(tǒng)一的日志平臺，用于支持搜索。而日志往往包含了最詳盡的業(yè)務(wù)信息，從某種意義上而言，這些日志可能是在誘導(dǎo)犯罪。(不知道是不是對前文中關(guān)于臨時身份有印象，拿到這些臨時身份的令牌，就可以完成身份竊取)

一類風(fēng)險是正式這些日志信息造成，我們需要有明確的規(guī)定有指導(dǎo)數(shù)據(jù)記錄，例如敏感信息、個人隱私信息、令牌、身份等信息，不要存儲全文，需要進行部分的模糊化。

另一類風(fēng)險正是引入日志平臺其本身帶入的風(fēng)險。

日志的具體配置不當(dāng)，例如本地的日志文件存放到了web的相關(guān)目錄，從而能直接訪問，造成大量信息泄露。(相關(guān)實例可自行搜索)

5. 場景三 權(quán)限配置

目前越來越來多的應(yīng)用支持復(fù)雜的權(quán)限配置和資源配置，有效維護這類信息，能夠大幅度降低安全風(fēng)險。

具體涉及的權(quán)限內(nèi)容，可查看訪問控制策略章節(jié)了解

七、軟件技術(shù)棧

1. 概念

軟件技術(shù)棧——我姑且這么寫如果有更好的名稱可以私信我，這里主要想提一提應(yīng)用系統(tǒng)中那些無法進行掌控的第三方組件，例如java的第三方j(luò)ar、框架、中間件。

對于現(xiàn)在的應(yīng)用程序而言，從零開始的搭建已經(jīng)有點不可能了，不是技術(shù)不可能，而是業(yè)務(wù)上不可能，我們需要速度，在已有輪子的前提下，肯定不需要再造輪子，即使造輪子，你有能力保證造的輪子就比別人的好使嗎?

但是呢，這類第三方的代碼與我們編寫的代碼在運行時共享的是同樣的權(quán)限、系統(tǒng)資源，如果這些代碼出現(xiàn)了問題，又當(dāng)如何?

2. 風(fēng)險與處理

至少需要能管理、了解到底用了哪些第三方的代碼。唯有這樣，在相關(guān)的第三方出現(xiàn)安全問題時，能夠快速響應(yīng)，做到止損。(相關(guān)工具：SCA——軟件成分分析軟件)

盡可能不使用存在已知問題的組件，不使用停止維護/維護不當(dāng)?shù)牡谌絻?nèi)容(如果是開源的，己方有能力維護可以不納入考慮)。

八、敏感數(shù)據(jù)

敏感數(shù)據(jù)現(xiàn)在是屬于法律法規(guī)領(lǐng)域最關(guān)注的一個點了，雖然互聯(lián)網(wǎng)上的應(yīng)用五花八門，但是所有這些虛擬身份的背后都是一個唯一的實體人。生命以負(fù)熵為食，人天生喜歡規(guī)律也是有規(guī)律的，大量數(shù)據(jù)可能能夠重新去定義一個實體人，通過定向的投放去影響和控制人，甚至盜取這個人的現(xiàn)實身份，這也是為什么敏感數(shù)據(jù)會成為各國法律法規(guī)的關(guān)注點。

所以在應(yīng)用系統(tǒng)設(shè)計的初期，我們必須需要明確哪些是所謂的敏感數(shù)據(jù)，以及圍繞著敏感數(shù)據(jù)的生命周期要如何處置

1. 哪些是敏感數(shù)據(jù)

個人隱私

CISSP ALL in One 在隱私章節(jié)里給出部分屬于隱私的數(shù)據(jù)類型，如下：

• 敏感的業(yè)務(wù)數(shù)據(jù)
• 財務(wù)相關(guān)交易記錄
• ……需要根據(jù)具體內(nèi)容去決定

2. 敏感數(shù)據(jù)的生命周期

一般而言，生命周期至少包括數(shù)據(jù)的產(chǎn)生、存儲、使用、銷毀，該過程映射到實際的應(yīng)用系統(tǒng)中可能還需要進行更加細(xì)節(jié)的處理。

傳輸：應(yīng)用系統(tǒng)涉及到信息交互，那么首先要新增的一個過程就是傳輸，在傳輸過程中的敏感信息要如何進行處理是需要進行明確。明文傳輸肯定是不行的。

產(chǎn)生：

• 我覺得更明確的詞，應(yīng)該是采集。
• 采集就涉及到到底是采用完整的數(shù)據(jù)，還是部分關(guān)鍵即可，如果是部分關(guān)鍵，那么將采集出的數(shù)據(jù)直接轉(zhuǎn)成Hash摘要可作為一種參考方式。

存儲：

• 避免明文存儲
• 如果不需要明文的敏感數(shù)據(jù)，建議采用hash算法等方式轉(zhuǎn)化數(shù)據(jù)，僅用于對比
• 如果需要明文的敏感數(shù)據(jù)進行操作，建議采用加密算法保障
• 其他情況

使用：使用可能涉及到多個場景，例如客戶端頁面的展示、業(yè)務(wù)操作的需要，如不必要進行展示，盡量不進行展示。

銷毀：一般這類敏感數(shù)據(jù)是需要提供銷毀數(shù)據(jù)的功能的，是真正從數(shù)據(jù)庫清空相關(guān)信息，而不是通過標(biāo)志位實現(xiàn)的假刪除方式

注意： 這里的說明，僅僅是提供敏感數(shù)據(jù)相關(guān)策略的參考，具體內(nèi)容以相關(guān)的法律法規(guī)以及業(yè)務(wù)自行設(shè)計。

九、輸入輸出

1. 概念

輸入與輸出，絕大多數(shù)的漏洞都在體現(xiàn)在這方面，假如一個系統(tǒng)完全沒有輸入和輸出，開個玩笑，如果真有這個系統(tǒng)，有和沒有又有什么區(qū)別?

輸入與輸出，這兩個詞雖然簡單但是里面缺少了一個東西——主體，什么東西的輸入輸出。

假如實體服務(wù)器，那么輸入輸出基本上就是我們在通信鏈路上來回輸送的數(shù)據(jù)，但是這些數(shù)據(jù)有點駁雜，沒有辦法再進一步的處理，唯一能做是采用一些全局的過濾器或者攔截器，但是誤殺又太高。

所有站在這個維度，雖然實現(xiàn)起來相對容易，但是把握度的難度會比較困難

假如把實體的粒度劃的再細(xì)一點，定義成應(yīng)用軟件(軟件，而非系統(tǒng))。從這個維度來看，系統(tǒng)的輸入和輸出類型就豐富來起來

• 輸入：來自文件系統(tǒng)上的文件、數(shù)據(jù)庫中的數(shù)據(jù)、中間件/容器傳遞的業(yè)務(wù)數(shù)據(jù)、其他組件的數(shù)據(jù)輸入、
• 輸出：文件系統(tǒng)、數(shù)據(jù)庫、其他組件、中間件/容器

此時的輸入輸出可以看得出與部分漏洞有了聯(lián)系，例如與文件系統(tǒng)相關(guān)的文件上傳漏洞、任意文件讀取漏洞

記住，原則上一切的輸入和輸出都不可信，只是經(jīng)過校驗和過濾的數(shù)據(jù)才能提高可信度。

2. 風(fēng)險與處理

通過縮小實體的粒度，我們更加明確了輸入與輸出，后續(xù)的風(fēng)險便是圍繞著具體的輸入信息和輸出的信息進行分析，構(gòu)建針對性的過濾和處理。

當(dāng)然，這種方法因為縮小了粒度所以在實現(xiàn)上就要復(fù)雜的多，主要是分析工作量增大，需要有針對性。