2009-01-24 42 views
0

在我的C#asp.net webform上我有一個搜索頁面,其中大約有20個元素「可以」用作搜索的一部分。稍後會添加更多內容。C#asp.net從viewstate動態構建SQL查詢

我所做的是擴展的文本框,下拉列表框,包括幾個變量:

字段名:Tablename.columnname DBTYPE:DbType.Int32 Joinparam:LEFT JOIN上otherTable ON XY = AB

這些都存儲在視圖狀態並加載回來。我這樣做的原因是,我可以遍歷所有控件並提取所有類型的控件。然後,我可以驗證它們,確保它們有輸入並且類型正確。如果是的話,我可以將它們傳遞給數據庫訪問層,並讓代碼動態生成SQL語句。

我不讓任何東西,但SELECT語句從此發生。選擇並返回的字段不能更改,我使用dbparameter嘗試並避免sql注入。

我的擔心是我把表和字段名稱,將用於搜索條件和JOINS需要所有的視圖狀態。這是一個真正的壞主意嗎?

我可以通過只在表中存放一些int索引來阻止這種情況,這些表將數據保存在數據庫中,但這仍然需要放入視圖狀態,這意味着它們會有一個額外的層。

我之所以採用這種方法,是因爲我不想在數據庫層中放置大量的IF語句來在那裏構建語句。這將是醜陋的地獄和一個痛苦的維持。

感謝您對此的任何建議。

喬恩

編輯

感謝所有的建議。謝天謝地,這個應用程序只是一個內部的東西,所以損害會受到限制。但是我絕不會再使用這種技術,而是會改用搜索模板的想法。

乾杯:)

回答

3

我認爲這是一個真正的設計錯誤編碼您的數據訪問層的部分在您的視圖邏輯。拋開安全問題,對於任何追隨你的人來說,這將很難保持和理解。我認爲從長遠來看,從各種選定輸入中產生特定查詢的工廠類可能會更容易處理。或者,您可以從輸入中填充「搜索模板」,並將搜索模板功能作爲生成查詢的工廠,就像UserPrincipal與System.DirectoryServices.AccountManagement命名空間中的PrincipalSearcher進行交互的方式一樣。

+0

嗨蒂凡,我可以看到你的話。我怎樣才能將你的搜索模板和網頁鬆散地鏈接起來,以便它知道哪些變量應該映射到哪裏而不會泄露任何安全問題? – Jon 2009-01-24 22:23:43

2

Viewstate未加密,它是base64編碼的。有實用工具可以讓您解碼頁面的視圖狀態。

它可以用於一個頁面或所有但你的頁面視圖狀態進行加密: http://msdn.microsoft.com/en-us/library/aa479501.aspx

這就是說,我不會推薦這種方法。應用程序設計的最佳方法是將您的用戶界面與業務和數據訪問邏輯分離。在這種情況下,你會緊密結合他們沒有明顯的好處。

如果您確實在數據訪問層中構建了更強大的即席查詢功能,那麼您可能會爲應用程序的後端添加值。您可以通過Web服務,Windows窗體應用程序等提供搜索功能。即使這種類型的功能不是您想要在不久的將來發生的事情,但採用此方法時,它可能會是一個很大的時間(和$$$)保存。

您在UI中構建的邏輯可以很容易地構建到某種類型的查詢引擎中。您可以通過動態添加標準來構建查詢來組裝查詢的方法,而不是您想要避免的IF。

+0

謝謝吉姆。我沒有意識到它只是編碼......這不是很好,(對於我來說)。 – Jon 2009-01-24 22:38:01

1

好的,所以ViewState默認爲MACed,並且可以選擇加密。所以,雖然你可以(默認)閱讀視圖狀態,tampering isn't trivial。如果我可以在你的JOIN子句中注入一個DROP TABLE語句,那麼你就會陷入困境(除非你「當然,我已經非常謹慎地設置數據庫級別的安全性)。

這就是說,我沒有看到任何理由,您的JOIN子句和這樣的將永遠需要在ViewState中。我想你會將它們設置爲ASPX標記中的子文本文本框的屬性 - 他們沒有理由更改。你可能需要ViewState的唯一的事情就是搜索條件本身 - 這是適當的參數化。這與SqlDataSource如何保護它的SelectCommand屬性類似 - 不要將它存儲在ViewState中,以免泄漏信息(或者冒着被篡改的風險 - 雖然我認爲這不是一個嚴重的漏洞)。

至於這是否可維護的更大問題 - 好吧,您必須撥打我想的電話。