爲數據庫分隔讀寫用戶是一種很好的安全措施嗎？

Question

因此，如果代碼的某些部分容易出現sql注入，那麼至少用戶不能向數據庫寫入任何內容，前提是他碰巧使用的是對所有內容都沒有通用寫入權限的前端？

Answer 1

是的，我認爲最好讓用戶使用僅允許他們使用該站點所需最少權限的帳戶進行連接。如果您的網絡用戶只應該從數據庫中讀取數據，那麼我肯定會創建一個只具有讀取訪問權限的賬戶，並通過它訪問數據庫。

更重要的是保護您的Web應用程序。即使用戶沒有寫入數據庫（認爲信用卡號碼或密碼被盜），您仍然可能成爲破壞性SQL注入攻擊的受害者。

Answer 2

該方法通常具有不同的角色，而不是真正的用戶本身。就SQL注入攻擊而言，我會集中精力解決問題，而不是通過您提出的這種方法來緩解問題。

Answer 3

是的，但是有很多設計技術可以幫助控制您的數據庫接口和表面積。

必須假定代碼通常在給定會話（讀取和寫入）中對其所有操作使用相同的登錄名。但是，如果用戶不是寫作用戶，則用於他的會話的登錄名肯定沒有任何寫入權限。

減少暴露於SQL注入的表面積的一個好方法是不要讓該帳戶能夠直接更新任何表。例如，通過存儲過程的寫入訪問，唯一可能發生的注入是使用適當的參數執行這些過程。

Answer 4

大多數情況下，這是過度殺毒，但大多數情況下，您應該使用參數化查詢，而這些查詢無論如何都不傾向於SQL注入。

考慮使用存儲過程以及只能調用過程的用戶帳戶，而不是直接運行查詢。

如果您需要使用直接查詢，並且出於某種原因無法使用參數，那麼是的，您應該有一個用戶帳戶，只有在可能的情況下才能從數據庫中讀取數據。

Answer 5

是的。除了Abe和Cade Roux的良好答案之外，它還可以幫助安全審計員確定優先次序，並使攻擊後的取證更容易。

它允許您將安全審計集中在使用更多權限的代碼上 - 您可以花更多時間審計需要寫入權限的代碼，而不是需要讀取權限的代碼，並且需要更多時間處理需要刪除表權限的代碼。

角色分離的另一個好處是它使取證更容易。如果您有角色分離並且可以識別數據庫日誌中的攻擊，則可以縮小可能被利用的代碼的範圍 - 僅限於使用與日誌中的攻擊關聯的角色的代碼。

Answer 6

看起來你的SQL注入想法來自於Bobby Tables那個愚蠢的漫畫。
但實際上，從數據庫中讀取數據可能比寫入更具災難性。

另外，我有一種強烈的感覺，那就是那個說「這是好習慣」的好傢伙的NOBODY在現實生活中使用它。比如說，前端（在真實而不是虛構的生活中）也必須具有寫入權限。

你在吠叫錯誤的樹。
如果您有部分代碼傾向於sql注入 - 更正這些部分。這是唯一的理智解決方案。