2017-10-11 16 views
1

對於我們ASP.NET(針對SQL Server)應用程序內的一些功能,我們允許員工用戶指定WHERE子句。這個WHERE子句然後被添加到系統生成的SELECT語句的代碼中以檢索一些數據。保護數據輸入SQL以防止不良行爲

所以在本質上,我們結束了:

SELECT SomeFields FROM SomeTable WHEREUserEnteredWhere

其中大膽是系統和斜體是用戶。這已經工作了一段時間,並給了我們一些很好的靈活性。

然而顯然還有這裏一個很大的問題,如果用戶輸入,其中:

SomeField = 1; DROP TABLE SomeTable;

目前唯一的驗證語句是否與SELECT開始,將通過,因爲我們將結束:

SELECT SomeFields FROM SomeTable WHERESomeField = 1; DROP TABLE SomeTable;

長期的解決辦法是不允許用戶輸入SQL到文本框,但在短期內我要撐住這件事。

我能想到的唯一解決方案是在交易中運行每個請求以確保不會造成長期損害。

有沒有人對我如何驗證用戶輸入的「where子句」有任何建議,以確保它在執行之前沒有任何DDL內容?

PS。我意識到上述情況很糟糕,不應該這樣做,但這是我在遺留系統中所做的(我沒有寫過),所以請儘量幫助我解決問題,而不是告訴我不要這樣做。 :-)

+1

限制接入是另一種方式。如果用戶沒有權限放棄,他不會放棄它。希望有人會添加更多的細節。 –

+0

我認爲保存的方法是驗證任何輸入的單詞,並檢查輸入的單詞是否包含任何錯誤的動作命令,然後再將它傳遞到SQL查詢中。 – Saif

+0

你如何「我們允許員工指定WHERE子句」?如果您允許用戶傳遞一個鍵/值對列表,然後自己構造查詢,該怎麼辦? asp.net服務帳戶仍然有權限(另一個安全軸,您可以像別人提到的那樣修復),最終用戶實際上並不需要直接訪問,是嗎? – Tipx

回答

1

因爲我需要一個快速解決我最終結束了從事物的SQL Server端解決這個:

  • 通過利用.NET中一個單獨的連接這些數據庫 相互作用。牛逼
  • 用戶被鎖定,只允許SELECT語句 如下:

SQL:

CREATE LOGIN MrReadOnly 
    WITH PASSWORD = 'LetMeIn!'; 

USE MyDatabase; 
CREATE USER MrReadOnly FOR LOGIN MrReadOnly; 
GO 

EXEC sp_addrolemember N'db_datareader', N'MrReadOnly' 
3

您知道正確的答案 - 您已將您的應用程序暴露給SQL注入。一般而言,特設解決方案並不健全。而且,把這個陳述放在交易中並沒有幫助。畢竟,commit可能是其中的一個命令。

某些接口具有「執行單個查詢」的等效功能。這幾乎可以解決您的問題,因爲第二個查詢會在應用程序中產生錯誤。

我建議不允許任何的在用戶生成的條件以下字符/關鍵詞:

  • ;
  • update
  • delete
  • insert
  • create
  • exec
  • grant
  • 甚至更​​多
  • ,也可能select(除非你想支持子查詢)

這可能會限制在一定程度上什麼是允許的條件。

這不是針對注射的保證,但應該讓事情變得更好。

+0

最初我正在考慮禁止COMMIT並在交易中包裝它。這樣最終不會改變。不是很好,但更簡單的檢查比添加到永不結束的列表。 – TheEdge