OWASP-Top4-(Insecure Design不安全設計)


A04:2021 – 不安全的設計

概述

2021 年的新類別側重於與設計和架構缺陷相關的風險,並呼吁更多地使用威脅建模、安全設計模式和參考架構。值得注意的CWE包括 CWE-209:生成包含敏感信息的錯誤消息、 CWE-256:未受保護的憑證存儲CWE-501:信任邊界違規CWE-522:受保護的憑證不足

 

官方的描述

不安全設計是一個廣泛的類別,代表許多不同的弱點,表現為“缺失或無效的控制設計”。缺少不安全的設計是缺少控制的地方。例如,想象一下應該加密敏感數據的代碼,但沒有方法。無效的不安全設計是可以實現威脅的地方,但域(業務)邏輯驗證不足會阻止該操作。

安全設計是一種文化和方法,它不斷評估威脅並確保代碼經過穩健設計和測試,以防止已知的攻擊方法。安全設計需要安全的開發生命周期、某種形式的安全設計模式或鋪砌道路組件庫或工具,以及威脅建模。

 

CWE-209:生成包含敏感信息的錯誤消息

我們所熟悉的應用程序未容錯也是屬於這種,以一個登錄界面為例

如果登錄的時候涉及到內容的加密和解密.

那么登錄時用非常規手段傳了一串非法的字符串進行登錄.在解密的時候可能會出現一些異常,如索引越界,這樣就會把異常的英文內容直接提示給頁面了。

應該在編寫代碼的時候在登錄接口中處理異常的時候, 要根據不同的異常進行處理. 業務的異常, 如密碼錯誤,賬戶凍結等, 就按業務異常提示.其他意外的錯誤, 則統一給提示語, 屏蔽掉異常的英文內容,防止通過攻擊者構造不同的。

 

 CWE-522:受保護的憑證不足

可以說CWE-522包括了CWE-256:未受保護的憑證存儲

示例

此代碼更改用戶的密碼。

糟糕的 PHP

 

$user = $_GET['user'];
$pass = $_GET['pass'];
$checkpass = $_GET['checkpass'];
如果($pass == $checkpass){
SetUserPassword($user, $pass);
}

 

雖然代碼確認請求用戶輸入了兩次相同的新密碼,但並不能確認請求更改密碼的用戶是將要更改密碼的同一用戶。攻擊者可以請求更改其他用戶的密碼並控制受害者的帳戶。

示例

以下代碼從屬性文件中讀取密碼並使用該密碼連接到數據庫。

糟糕的Java

 

...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");
DriverManager.getConnection(url, usr, 密碼);
...

 

此代碼將成功運行,但任何有權訪問 config.properties 的人都可以讀取密碼的值。如果不正當的員工可以訪問此信息,他們可以使用它來闖入系統。

 

這個CWE在我看來利用成功會更加偏向與后滲透的那一塊,或許能夠獲取到更多數據庫的信息,對於偷盜數據,脫褲可能有幫助。

 

 

CWE-501:信任邊界違規

 

先說說什么是信任邊界,可以這樣畫一條線,一邊是低信任區域,一邊是高信任區域

 

 

未通過安全驗證就從低信任到高信任區域的請求是不安全的,比如http的get和post請求傳遞的參數就是不受信任的

應該對傳入的參數值進行安全檢測,否則則會造成信任邊界違例。如果沒有建立和維護良好的信任邊界,開發者將不可避免地失去對數據驗證的跟蹤。這種混亂最終會導致一些數據在沒有驗證的情況下被使用。

 

下面這個代碼就是直接獲取username進行使用,並沒有驗證username是否可信任

就直接使用了

 

 

 修復方法:

在開發階段,增加驗證邏輯,讓數據安全地穿過信任邊界,即從不受信任的一邊移到受信任的一邊。

 

 

攻擊場景示例

場景 #1:憑證恢復工作流程可能包括“問答”,這是 NIST 800-63b、OWASP ASVS 和 OWASP Top 10 所禁止的。不能將問答作為多個人身份的證據可以知道答案,這就是為什么它們被禁止。此類代碼應刪除並替換為更安全的設計。

場景#2:連鎖影院允許團體預訂折扣,並且在要求押金之前最多有 15 名參與者。攻擊者可以對該流程進行威脅建模,並測試他們是否可以在幾次請求中一次預訂 600 個座位和所有電影院,從而造成巨大的收入損失。

場景 #3:零售連鎖店的電子商務網站沒有針對由黃牛運行的機器人提供保護,這些機器人購買高端顯卡以轉售拍賣網站。這對視頻卡制造商和零售連鎖店主造成了可怕的宣傳,並與無法以任何價格獲得這些卡的愛好者之間產生了仇恨。仔細的反機器人設計和域邏輯規則,例如在可用性的幾秒鍾內進行的購買,可能會識別出不真實的購買並拒絕此類交易。

 

 

 

如何預防

  • 與 AppSec 專業人員建立並使用安全的開發生命周期,以幫助評估和設計與安全和隱私相關的控制

  • 建立和使用安全設計模式庫或准備使用組件的鋪好的道路

  • 將威脅建模用於關鍵身份驗證、訪問控制、業務邏輯和關鍵流

  • 編寫單元和集成測試以驗證所有關鍵流都能抵抗威脅模型

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM