上周，我們告訴您有關一項研究的發(fā)現(xiàn)，這些研究在Stack Overflow答案中發(fā)現(xiàn)了一些C ++代碼片段中的安全漏洞，以及其中的某些漏洞是如何遷移到實際的，實時的Github項目中的。今天，我們跟蹤研究中突出顯示的前八種錯誤類型，并提出避免發(fā)生相同錯誤的方法。 

為了獲得這些答案，我們檢查了通用弱點枚舉數(shù)據(jù)庫中Verdi等人在其研究中發(fā)布的數(shù)字。我們只針對涉及特定弱點而不是類別的CWE編號，因為在開始解決這些弱點之前，它們需要一些更多的信息。 

盡管研究專門在C ++代碼段中發(fā)現(xiàn)了這些漏洞，但下面提到的CWE可以在多種編程語言中發(fā)生。其他編程語言可能更傾向于其他CWE，因此請不要將此作為安全性檢查清單。

事不宜遲，如果您遇到問題，喲，我會解決。 

CWE-754 錯誤檢查異常或異常情況

此漏洞的發(fā)生是基于以下假設：事件或特定情況不會發(fā)生，例如內(nèi)存不足，無法訪問資源。

在給定的程序中，您可能能夠控制大多數(shù)數(shù)據(jù)流，因此可以假定所有函數(shù)返回值都在期望值之內(nèi)。但是罕見的事件仍然可能發(fā)生。更糟糕的是，有時聰明的攻擊者會觸發(fā)這些事件并給您的系統(tǒng)造成破壞。 

您可以通過假設總是在需要時成功分配內(nèi)存，文件或字符串具有特定大小，或者數(shù)據(jù)庫或輸入調(diào)用將返回非NULL的內(nèi)容來暴露此弱點。在許多情況下，意外數(shù)據(jù)將使進程崩潰。也許您的代碼可以優(yōu)雅地處理此問題?；蛘撸到y(tǒng)可能會繼續(xù)處于意外狀態(tài)，從而使系統(tǒng)容易受到攻擊者的欺騙。 

最近，一個以太網(wǎng)/串行RTU模塊暴露了這一弱點。盡管該漏洞可能已得到修補，但以前，攻擊者可以通過將截斷的SNMP數(shù)據(jù)包發(fā)送到特定的UDP端口來發(fā)起拒絕服務攻擊，或者通過另一個端口上的大量數(shù)據(jù)包斷開連接來斷開所有連接。 

某些語言可能能夠在造成危害之前捕獲這些異常。但是對于沒有的低級語言，您可以執(zhí)行以下操作：

• 每次檢查您的返回值

• 假設所有輸入都是惡意的，并且僅接受某些值

• 計劃低資源條件

• 失敗的建筑師

異常和失敗管理并不能解決所有問題。過于冗長和特定的異常會為攻擊者提供有關如何在代碼中查找其他漏洞的線索。 

CWE-20 輸入驗證不正確

當軟件無法正確驗證輸入時，攻擊者便能夠以應用程序其余部分所不希望的形式編寫輸入。

俗話說“垃圾進，垃圾出”。如果您的輸入不正確，則可能會導致某些不良結(jié)果。這有點像惡作劇，在那兒您咬咬了您認為是Lindor松露中的一種，但實際上是巧克力包裹的抱子甘藍。惡意攻擊者將試圖向您提供一些比抱子甘藍更糟糕的輸入。 

這種弱點與上一個弱點有一個共同點，即開發(fā)人員假定沒有人可以訪問其功能中的輸入。錯誤的開發(fā)者名單很 長。 

某些版本的MS Excel（所有版本都已使用10年或以上）允許用戶在加載電子表格后在系統(tǒng)上執(zhí)行任意代碼。惡意電子表格中嵌入的各種對象都訪問了VBA性能緩存，該緩存在運行時未進行清理，因此其行為異常。 

尤其是在具有數(shù)據(jù)庫驅(qū)動的后端的網(wǎng)絡應用程序中，軟件具有大量矢量，用于不受信任的輸入。您可能會認為，每次都可以通過清潔輸入來克服此弱點，但是還有很多其他安全措施可采?。?/span>

• 檢查客戶端和服務器上的輸入值

• 對于來自多個來源的任何輸入值組合，請驗證組合值以及輸入

• 注意跨語言的代碼，例如在本機虛擬機上運行的解釋語言中會發(fā)生這種情況

• 明確將您的輸入轉(zhuǎn)換為預期的數(shù)據(jù)類型

• 驗證之前，請確保所有數(shù)據(jù)都在規(guī)范字符編碼方案中

• 使用靜態(tài)分析

CWE-252 未檢查的返回值

方法或函數(shù)不檢查返回值，這可能會導致意外狀態(tài)。

您可能現(xiàn)在已經(jīng)注意到一個主題：在破壞自己之前先檢查一下自己?；蛘?，更簡單地說，驗證所有數(shù)據(jù)以確保它是您想要的。如果您查看某個函數(shù)并認為它永遠不會失敗，或者認為它是否失敗都沒有關系，那么您將自己暴露于此漏洞中。 

與以前的弱點類似，此弱點可能會使系統(tǒng)處于意外狀態(tài)，從而導致崩潰或其他異常，包括執(zhí)行任意代碼。這就是2007年許多Linux實施中發(fā)生的情況。攻擊者可能將TLV數(shù)據(jù)包偽造為BGP數(shù)據(jù)包，從而使他們可以執(zhí)行所需的操作。這特別危險，因為BGP數(shù)據(jù)包通常由自治系統(tǒng)傳遞以共享路由信息。 

緩解這個問題很簡單：檢查您的返回值，確保它們在預期范圍內(nèi)，如果不是，則拋出異常。 

CWE-477 使用作廢功能

該代碼使用了不推薦使用或過時的功能，這表明該代碼尚未得到積極的審查或維護。

隨著漏洞的發(fā)現(xiàn)和軟件實踐的改變，語言和軟件可能會過時地淘汰某些功能。盡管您可以繼續(xù)使用已棄用的功能，但這樣做可能會出現(xiàn)安全問題。而且某些函數(shù)（例如rand（））對于嚴肅的代碼可能已經(jīng)過時了。 

該弱點可能表明的一個更嚴重的問題是，有關軟件沒有得到維護或更新。如果沒有人跟上軟件和系統(tǒng)的變化，過時的功能可能會持續(xù)存在。在未維護的系統(tǒng)中，安全漏洞會隨著軟件的老化而滾滾滾滾。問題有時會得到新的答案，但是對于多年前發(fā)布在Stack Overflow上的代碼段，沒有人維護（也不應該維護），因此要確保所有內(nèi)容仍然安全。 

在2018年的NUUO CMS中，過時的軟件組件使用戶可以隨意執(zhí)行代碼。在具有大量依賴關系的復雜軟件中，甚至不需要您的代碼就具有安全性弱點即可將其暴露于威脅中。 

即使沒有實現(xiàn)，緩解此缺陷的方法也很簡單：重構(gòu)代碼以避免過時或過時的功能。如果需要使用這些功能，請確保您了解安全隱患并制定相應的計劃。 

CWE-789 不受控制的內(nèi)存分配 

根據(jù)無效大小分配內(nèi)存，從而可以分配任意數(shù)量的內(nèi)存。

內(nèi)存分配是一個非常常見的功能，尤其是在低級語言中。但是，如果代碼分配了大量的內(nèi)存，則可能導致系統(tǒng)變慢或崩潰。盡管系統(tǒng)故障已足夠嚴重，但在靈活的云系統(tǒng)上，過度分配可能會非常昂貴。 

這是CWE-20（輸入驗證不正確）的表象，因為需要驗證的輸入正提供給內(nèi)存分配功能。內(nèi)存可能越來越便宜，但仍然有限。如果攻擊者可以占用您硬件上的所有內(nèi)存，則不僅可能使您的程序崩潰，而且可能使該系統(tǒng)上運行的任何其他程序崩潰。 

在2008年，IBM solidDB沒有驗證設置要分配的內(nèi)存量的字段。因此，只要在此字段中提供較大的值，任何傳入的數(shù)據(jù)包都可能使系統(tǒng)崩潰。由于solidDB已嵌入許多網(wǎng)絡和電信設備中，因此此弱點可能會對Internet的基礎結(jié)構(gòu)造成很多破壞。 

緩解這個問題的方法與上面的CWE-20相同，另外還要確保您沒有超出系統(tǒng)的內(nèi)存限制。 

CWE-158 空字節(jié)或空字符的不正確中和

輸入是從上游組件接收的，但是當空字節(jié)發(fā)送到下游組件時，它不會中和或錯誤地中和。

在C ++中，字符串以null字符終止。在大多數(shù)情況下，這可以提供很大的靈活性，因為字符串可以是任意長度。但是用戶可以輸入任意數(shù)量的字符作為輸入，包括在字符串中間的空字符。在這種情況下，字符串將被截斷為該null。 

在大多數(shù)情況下，這無關緊要。但是，如果將該字符串作為一個較長的字符串（例如URL或用戶名）的一部分進行組合，則他們可能能夠使程序放棄超出預期的范圍。雖然這個問題是關于PHP的，但是技術是相同的。輸入中的空字符可以取消附加到該字符串的所有內(nèi)容，包括使該文件名成為文件擴展名的文件擴展名。借助一些巧妙的腳本，惡意代理即可遍歷Web目錄并獲取所需的任何文件。 

這是許多早期的Web服務器中發(fā)生的情況。攻擊者可以在URL末尾添加一個空值并列出目錄，讀取源代碼，并且通常繞過所有訪問限制。然后，這些源文件將提供有關可被利用的系統(tǒng)的許多其他信息。 

在嘗試捕獲這些攻擊時，您的代碼應假定有人輸入的內(nèi)容為空。這是保護代碼的幾種方法：

• 刪除輸入中的空字符 

• 使用規(guī)范方法顯式編碼輸入

• 結(jié)合使用白名單和黑名單來指定有效值并阻止無效值

CWE-134 使用外部控制的格式字符串

該軟件使用的函數(shù)接受格式字符串作為參數(shù)，但是格式字符串源自外部源。

諸如printf（）之類的格式函數(shù)采用具有格式函數(shù)的String并將其轉(zhuǎn)換為常規(guī)String。格式參數(shù)看起來像％x，它將處理函數(shù)中的參數(shù)，并將其添加到返回值中。但是，如果String是由外部控制的（即，作為輸入或從文件/數(shù)據(jù)位置讀?。⑶椅凑_驗證，則攻擊者可能會將自己的參數(shù)放入函數(shù)中。 

一些參數(shù)允許從存儲器堆?；蜻^程存儲器讀取和寫入。允許來自任意用戶輸入的數(shù)據(jù)是一個非常糟糕的主意。攻擊者可以從內(nèi)存中讀取信息或執(zhí)行任意代碼，具體取決于格式字符串中的內(nèi)容。 

2006年，Dia（一種基于GTK +的圖表工具）在嘗試連續(xù)打開一個以一堆％s命名的bmp文件時，允許拒絕服務攻擊（并可能執(zhí)行代碼）。該軟件將嘗試顯示帶有文件名的警告消息，但是由于它正在處理格式參數(shù)，因此它顯示的是敏感信息。 

解決方案非常簡單：確保傳遞給格式函數(shù)的所有Strings都是靜態(tài)的并且在控件內(nèi)。有時，編譯器警告會指出存在問題的區(qū)域，因此請不要忽略它們。 

CWE-476 空指針引用

當應用程序取消引用它期望是有效的但為NULL的指針時，就會發(fā)生NULL指針取消引用，這通常會導致崩潰或退出。

當一半的問題是由于空指針異常（或取消引用）而導致的，我仔細閱讀了發(fā)行說明。盡管許多空指針可能會使系統(tǒng)崩潰或?qū)е鲁绦蛞馔馔顺?，但有時它們會使系統(tǒng)處于意外狀態(tài)，即奇怪，不可復制的怪癖或從其他內(nèi)存地址提取數(shù)據(jù)。當攻擊者可靠地找到在系統(tǒng)中誘發(fā)空值的途徑時，它將成為安全問題。 

盡管許多空指針是由于草率的編程而發(fā)生的，但在異步系統(tǒng)中，空指針可能來自競爭條件。這是兩個異步進程讀取和寫入相同變量的地方。這些操作可能會無序發(fā)生，因此，當一個進程移動得更快并且在另一個進程有機會對其進行設置之前讀取該變量時，繁榮起來！空指針取消引用。 

在2004年，OpenSSL進行了空指針取消引用，這使攻擊者可以制定特定的SSL / TLS握手協(xié)議，使服務崩潰，從而有效地造成了拒絕服務攻擊。 

通過檢查從Stack Overflow復制的代碼中的這些常見錯誤，可以避免很多嚴重的安全風險。分享一些知識，找出一些答案，并在那里保持安全。