存儲過程與無存儲過程 - 安全視點

Question

Web應用程序的數據庫， 只從安全的角度看，有什么論據反擊的點的SP只有在應用數據庫帳戶對SPS表和視圖，只有高管沒有任何權利的解決方案？

如果某人攔截了應用程序數據庫帳戶，那么暴露於攻擊的表面區域就會比未暴露表格和視圖時要小得多。 非sp解決方案提供（或不提供）的安全優勢是什么？ 我看到使用非sp解決方案有很多好處，但暴露所有表格讓我有點擔心。

問題是一般的主要數據庫供應商產品，特別是sql server 2008。

Answer 1

僅從安全角度來看，我看不到非SP方法對SP方法的任何優勢，因為：

• 您必須直接向基礎表等授予權限
• 使用sproc，可以封裝/隱藏所有真實底層架構信息（SP也可以加密）

Answer 2

你的公司的會計系統就是我們需要一個真正安全的系統。 如果你使用procs並僅授予對procs的訪問權限，那么除了proc所做的事情之外，用戶不能做任何事情。 這是一個內部控件，旨在確保系統的任何用戶都無法獲得系統的業務規則。 這是阻止人們購買公司然后批准資金本身打開欺詐之門的原因。 這還可以防止組織中的許多人刪除帳戶表中的所有記錄，因為他們沒有刪除權限，除了從proc授予的權限，一次只允許刪除一次。

現在，開發人員必須擁有更多權限才能開發，但如果您想考慮安全性，他們就不應該擁有生產機器上的更多權限。 真的，一個開發人員可以編寫一個惡意的sp，它會在生產時做壞事。 同樣的開發人員雖然可以將相同的代碼放入應用程序版本中，但是可能會被捕獲或者不是因為他們惡意更改了proc。 我個人認為proc可能更容易被捕獲，因為它可能會被dbas與代碼分開，這可能意味着管理員或配置管理人員和dbas有機會只看經理或配置管理人員。 我們都知道現實是沒有人推動代碼生產有時間仔細審查每一部分，因此聘請值得信賴的開發人員至關重要。 進行代碼審查和源代碼控制有助於發現惡意更改或將其回滾到以前的版本，但無論如何使用sps副應用程序代碼都會受到開發人員的威脅。

系統管理員也是如此。 必須擁有系統的完全權限才能完成工作。 他們可能會在沒有被抓住的情況下造成很大的傷害。 在這種情況下，您可以做的最好的事情是盡可能少地限制這種訪問，並盡可能地雇用值得信賴的人。 至少如果您擁有此訪問權限的人很少，則在問題發生時更容易找到問題的根源。 您可以通過異地備份來最小化風險（因此，至少管理員如果轉壞，可以在某種程度上修復它們），但是您永遠無法完全擺脫這種風險。 無論您允許應用程序訪問數據的方式如何，這都是正確的。

所以sps的真正用途並不是消除所有可能的風險，而是為了減少人們對系統的傷害。 使用應用程序代碼來影響數據庫信息本質上是不安全的，我認為不應該允許存儲財務信息或個人信息的任何系統。

Answer 3

不使用存儲過程的最大安全優勢是清晰度。 通過查看對表的訪問權限，您可以准確了解帳戶可以執行的操作。 對於存儲過程，情況不一定如此。 如果一個帳戶具有執行過程X的能力，那么會限制帳戶執行該過程而不會觸及基礎表，但X可以執行任何操作。 它可以刪除表，更改數據，刪除數據等。

要了解帳戶可以對存儲過程執行的操作，您必須查看存儲過程。 每次更新一個sproc時，有人必須查看它的作用，以確保某些東西沒有被“意外”放入其中。 sprocs中安全性的真正問題來自組織內部，而不是來自流氓攻擊者。

這是一個例子：

假設您正在嘗試限制對employee表的訪問。 沒有存儲過程，您只是拒絕訪問該表。 要獲得訪問權限，必須要求您授予權限。 當然，他們可以讓你運行一個腳本來授予訪問權限，但是大多數人至少會嘗試查看改變數據庫模式的腳本（假設腳本沒有更新sproc，我將在下面討論）。

應用程序可能存在數百個存儲過程。 根據我的經驗，他們經常更新，在這里添加一個字段，在那里刪除一個。 對於某人來說，審查更新過程腳本的數量總是令人生畏，並且在大多數組織中，數據庫團隊開始只是快速查看過程（或者不查看所有過程），並將其移動。 這就是真正的問題所在。現在，在這個例子中，如果IT人員中的某個人想要允許訪問表，那么該人只需要放入一行代碼來授予訪問權限或執行其他操作。 在一個完美的世界中，這將被抓住。 我們大多數人都不在一個完美的世界里工作。

存儲過程的真正問題是它們為系統添加了一定程度的混淆。 隨着混淆帶來了復雜性，並且復雜性最終會使理解管理底層系統的工作更多。 IT部門的大多數人都過度勞累，事情也隨之消失。 在這種情況下，您不會嘗試攻擊系統以獲取訪問權限，您可以使用系統負責人來獲取您想要的內容。 米特尼克是對的，在安全方面人是問題。

對組織的多數攻擊來自內部。 無論何時將復雜性引入任何系統，都會出現漏洞，事情可能會被忽視。 不要相信，想想你的工作地點。 完成有關您要求訪問系統的人員的步驟。 很快你意識到你可以讓人們在適當的時候忽視事物。 成功地與人參與系統的關鍵是做一些似乎無害的事情，但實際上是顛覆性的。

請記住，如果我試圖攻擊系統：我不是你的朋友; 我對你的孩子或愛好毫無興趣; 我將以任何必要的方式使用你來獲得我想要的東西; 如果我背叛你，我不在乎。 “但他是我的朋友，這就是為什么我相信他相信他所做的事情是正確的”的想法，事后並不安慰。

Answer 4

這是傳統智慧正確的領域之一：只暴露存儲過程可以讓您更好地控制安全性。 直接訪問表和視圖更容易，有時您需要這樣做，但它的安全性會降低。

Answer 5

好吧，我猜你自己確實抓住了問題的核心：如果你不為所有CRUD操作使用存儲過程，你必須至少授予特定於應用程序的db用戶帳戶所有表的SELECT權限。

如果要允許db帳戶執行更多工作，該帳戶可能還需要其他權限，例如能夠在某些表上更新和可能刪除。

我沒有看到非存儲過程方法如何具有任何安全性好處 - 它確實打開了更多的門，問題是：你能負擔得起嗎？ 您能否足夠保護該應用程序特定的數據庫帳戶，以免影響系統的整體安全性？

一種可能的折衷方案可能是使用視圖或表訪問來允許SELECT，但使用存儲過程處理其他所有內容（UPDATE，DELETE，INSERT） - 半安全，一半方便......

通常情況下 - 這是方便（非sp方法;可能使用ORM）和安全（所有SProc方法;可能更麻煩，但更安全）之間的經典權衡。

渣

Answer 6

除了傳統的存儲過程安全分離（程序上的EXEC權限，依賴於數據訪問的所有權鏈接），存儲過程可以進行代碼簽名 ，從而對鏈接服務器， 服務器作用域管理等任何服務器功能進行非常精細和特定的訪問控制視圖 ，對存儲過程的受控訪問，甚至是用戶普通訪問之外的其他數據庫中的數據 。

在T-SQL批處理中進行的普通請求，無論多么花哨，以及代碼生成層和ORM層有多少層，都無法簽名，因此無法使用可用的最具體和最強大的訪問控制機制之一。

Answer 7

這是一個不完美的類比，但我喜歡將DB的“dbo”模式中的表與OO術語中的“私有”數據進行比較，並將“視圖和存儲過程”與“公共”進行比較。 甚至可以將“公共”模式與dbo模式分開，以使區分顯式化。 如果您遵循這一想法，您將獲得安全優勢以及可擴展性優勢。

一個帳戶（不是Web應用程序的帳戶）具有dbo訪問權並擁有數據庫，並且Web應用程序使用另一個僅限於面向公眾的結構的帳戶進行連接。

Answer 8

唯一可能的反對意見是我遇到了某些語句無法在SP中有效參數化的情況（並且需要動態sql），這使您可以進行in-SP SQL注入。 然而，這確實是一個非常狹隘的考慮因素，這是一種罕見的情況。 至少在PostgreSQL中我偶爾會看到一些需要額外審查的案例。

總的來說，即使在這些情況下，我認為SP類型方法在安全方面為您提供了一個好處，因為它們意味着應用程序可以使用通用的反SQL注入機制，否則可能無法實現，並且可以使用SP許多應用程序。 此外，如果所有活動都必須通過SP，那么您可以減少sql注入的風險並集中審核問題。

通常，用戶通常可以進行較少的安全性暴露。 這意味着用戶可以用sql注入攻擊做的事情越少。

存儲過程通常提供比沒有更好和更細粒度的安全性。

Answer 9

這里的大多數答案都指出了使用存儲過程的安全優勢。 在不忽視這些優點的情況下，還有一些未提及的大缺點：

• 數據訪問模式有時比正在執行的特定過程重要得多 。 我們希望記錄/監控/分析/提升訪問數據的警報/阻止，何時以及如何訪問。 使用存儲過程時，我們無法始終獲取此信息。

• 一些組織可能有大量的存儲過程 。 無法審查所有這些內容，並且關注表格可能更有意義（特別是在考慮存儲過程可能非常復雜，存在錯誤並引入其他安全問題時）。

• 有些組織可能需要分離關注點 。 數據庫管理員（或編寫存儲過程的任何人）並不總是安全人員的一部分。 安全人員有時需要只關注數據，因為他們不負責業務邏輯，而且編寫業務邏輯的人員並不完全信任。