數據庫訪問控制的解析及解決方案是怎樣的

這期內容當中小編將會給大家帶來有關數據庫訪問控制的解析及解決方案是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

數據庫訪問控制

規則描述

數據庫訪問控制是指程序未進行恰當的訪問控制，執行了一個包含用戶控制主鍵的SQL語句，由于服務器端對客戶提出的數據操作請求過分信任，忽略了對該用戶操作權限的判定，導致修改相關參數就可以擁有了其他賬戶的增、刪、查、改功能。如果在一個應用中，用戶能夠訪問他本身無權訪問的功能或者資源，就說明該應用存在訪問控制缺陷，也就存在越權漏洞。

漏洞危害

數據庫訪問控制是利用用戶引入的參數生成由用戶控制主鍵的 SQL 語句，令攻擊者可以訪問到同級別用戶的資源或者訪問更高級別用戶的資源，會導致任意用戶敏感信息泄露、用戶信息被惡意修改或刪除。數據庫訪問控制類似于數據庫越權。例如某一頁面服務器端響應中返回登錄名、登錄密碼、手機號、身份證等敏感信息，如果存在數據庫訪問控制，通過對用戶 ID 的遍歷，就可以查看所有用戶的敏感信息，這也是一種變相的脫庫，而且很難被防火墻發現，因為這和正常的訪問請求沒有什么區別，也不會包含特殊字符，具有十足的隱秘性。

整改方案

缺陷代碼

上述示例代碼31-56行，程序獲取用戶輸入的參數 id，并將傳入參數轉成 int 類型，然后創建數據庫查詢，查詢 uid 為傳入參數 id 的清單數據。顯然，程序中未對傳入參數做校驗及過濾，用戶可隨意獲得任何用戶的清單數據。

從跟蹤路徑中可以分析出數據的污染源以及數據流向，在代碼行第53行報出缺陷。

修復代碼：

在上述修復代碼中，在第34行從  session 中直接獲取到 id 的值構造查詢語句，獲得當前用戶的清單數據，避免用戶操控SQL語句的主鍵值。

1. 補充完整的解決方案：

發生構成該漏洞的兩個必要條件：

1、來自用戶或前端參數參與了后臺操作數據庫語句（數據從一個不可信賴的數據源進入程序）。

2、該參數做數據庫表主鍵使用（這個數據用來指定 SQL 查詢中主鍵的值。）

三種解決方案：

1. 可不使用來自用戶或前端參數做相關SQL操作（例：讀取session里值構建SQL（一般通過session取用戶id構建用戶清單，但如果產生漏洞的id不為用戶id，例：orgid，roleId，店鋪id取機構、店鋪信息時，則也需要保證該主鍵來自可信賴的數據源:后端或數據庫等地方））

2. 該參數不做SQL相關操作的主鍵使用。（使用一個與主鍵不一致的副id做相關操作）

例：圖1的查詢SQL語句

圖1

在圖2中查詢的org_id并未做主鍵id，而是作為的副id使用

圖2

且在圖3中核對該主副id不一致

圖3

3、參照fortify官方解決方式。

附加了一個限制，以驗證清單是否屬于當前經過身份驗證的用戶。

...

userName = ctx.getAuthenticatedUserName();

id = Integer.decode(request.getParameter("invoiceID"));

String query =

        "SELECT * FROM invoices WHERE id = ? AND user = ?";

PreparedStatement stmt = conn.prepareStatement(query);

stmt.setInt(1, id);

stmt.setString(2, userName);

ResultSet results = stmt.execute();

...

如上示例代碼：加入一個用戶名（不推薦使用用戶id）的查詢限制，匹配用戶對該條查詢是否有所有權。

上述三種解決方案:

方案1-->限制了構成漏洞的條件1；

方案2-->限制了構成漏洞的條件2；

方案3-->限制了操作越權的可能。

上述就是小編為大家分享的數據庫訪問控制的解析及解決方案是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。