2010-04-23 66 views
0

這回到我認爲的其他問題,我認爲是足夠的答案,但經過反思,我不確定它是(抱歉)。什麼阻止用戶將控件添加到ASP.NET頁面客戶端?

背景:

  1. 我動態生成的形式。我從數據庫中提取控件。

  2. 我必須和這不是用戶的會話ID數據庫ID每個控制關聯。我現在通過將我的ID存儲在Web控件的ID中以及其他一些東西來使它獨特/清楚我在做什麼。

  3. 在回帖中,我遍歷了網頁上的所有控件,檢查我的特殊標識符,即MyGeneratedTextBox_ID_Unique。該過程支持2個重要步驟,識別控件是我生成的,並且還獲取此輸入字段的ID。

而且,所有這些工作,但我仍然關心它的安全性。在這種情況下,我看不到顯示實際數據庫ID的安全問題,但同意這不是可取的。但是,我擔心的下列可能性:

  1. 如果用戶可以窮兇極惡的控件添加到我的收集和利用,對於SQL注入攻擊。

  2. 更學術,但是如果用戶能夠以某種方式存儲的領域,卻沒有改變的ID訪問過的數據。

我同意這是一種「黑客」的方式來做到這一點。但是我的問題是,這是一種安全風險嗎?是否有一種「簡單」的方式以較少的方式做到這一點?

我認爲只有所創建的實例化的頁面上的控件/添加到列表控件。因此所有控件必須創建服務器端,因此安全問題是地址,但只是想驗證。再次感謝。

PS: 我可以看到添加一個屬性,每個控制和加密的視圖狀態將是一個更安全一點。

回答

0

我想你自己回答是沒有錯的。但我覺得你仍然在混合一些東西(創建/實例化/控制的定義與恢復ViewState /狀態管理)。

可能的信息幫助明確了一點東西以下兩個部分:

非常熱烈建議的第二條對任何人使用ASP.NET (和ViewState)。

1

在他們具體說明,你應該在每個輸入執行輸入驗證ASP.NET 2.0的安全性原準則被張貼在瀏覽器的後退。確實沒有什麼能夠阻止某人將不同的數據發回給你的服務器端代碼。 ASP.NET中內置了一些最低限度的請求驗證,但他們明確聲明不依賴於此。

爲了保證數據的完整性,您應始終驗證從控件發回的每個單獨輸入。所有輸入應該通過去除不必要的特殊字符和可能指示攻擊媒介的模式來消毒SQL注入攻擊。如果你所依賴的只是控件的一個標識符,表示數據是好的,那麼你的驗證邏輯就有一個巨大的漏洞。

你應該在每個驗證輸入的格式是很好的,以及它有包含在它沒有任何問題的數據輸入執行服務器端驗證。

http://msdn.microsoft.com/en-us/library/ms998258.aspx

+0

@哈夫。對不起,我認爲你誤解了我的問題。我的問題可以有人創建一個新的控制/ ID或更改張貼的控件的ID?或者我可以依靠這些控件ID來永遠是我設置的,並且只依賴於我的控件被重新發布。 – 2010-04-23 20:53:32

+0

哈里說,任何人都可以發佈一個完全不同的id給你,而不是你設定的。 – nos 2010-04-23 21:22:06

+0

我想我已經回答了你的問題。你不能依賴客戶回報的任何東西,因爲你期望的。客戶完全無法控制。如果您保留打開的選項,其中可以將不同的控件發佈回您的服務器,而不是您預期會導致您不想要的行爲,則可以從客戶端實施該行爲。 – Harv 2010-04-23 21:22:17

0

我會盡量回答我的問題,因爲我認爲這是唯一的出路可能是:

唯一的服務器端控件獲得創建方法是在服務器上這樣你可以信任他們將擁有你設置的ID。這是必須在每個頁面實例化上創建控件的原因之一。你可能不相信任何表單提交的數據,但控制和身份證生成服務器端,因此是安全的。同樣,不可能編輯HTML以生成服務器端控件。

因此,即使它不夠優雅,我的方法也是比較安全的。唯一的安全缺陷是ID顯示。

1

我假設只有在頁面上創建/實例化的控件纔會添加到控件列表中,因此所有控件都必須創建服務器端,因此安全問題是地址,但只是想驗證。再次感謝。

您在服務器上用runat="server"創建的「實時」控件。您無需在控件集合中檢查您的特殊ID。正如Harv所說,您確實需要驗證控件的所有輸入。

沒有人可以將服務器控件添加到您的網頁,除非您的Web服務器可能已被入侵。

相關問題