2011-05-31 22 views
5

如果您正在檢查用戶的角色以確定他們是否可以訪問某個頁面,是否可以安全地只在if (!Page.IsPostBack) { ... }內部進行此項檢查? 客戶端可能導致Page.IsPostBack == true獨立於ASP.net;也就是說,客戶端POST到頁面並設置正確的表單域?如果可能的話,那麼我認爲最好的做法是檢查每個頁面加載的安全性,而不僅僅是當Page.IsPostBack == false是否可以導致Page.IsPostBack獨立於ASP.net爲真?

回答

0

對不起所有那些誰已經回答了,但我不同意,只有Page.IsPostBack == false塊內檢查安全授權是必然不安全(只要事件驗證和加密的視圖狀態是打開)。我已經解釋了爲什麼我認爲這是here,但簡短的答案是:我不認爲你可以欺騙回發到一個頁面,而無需先在非回發上下文中加載它以獲得viewstate和eventvalidation表單字段。返回的viewstate字段將導致您在Page.IsPostBack == false塊中隱藏的內容隱藏在使用該視圖狀態的任何回傳中,並且由於視圖狀態已加密,因此不會被篡改。

0

絕對可以獨立於ASP.Net發佈到URL。你甚至不需要瀏覽器。

您應該查看ASP.Net的內置身份驗證,授權和成員身份特性,而不是嘗試自行推出。

這裏有一個良好的開端:http://www.4guysfromrolla.com/articles/120705-1.aspxhttp://www.4guysfromrolla.com/articles/031204-1.aspx

+1

我知道你可以POST到一個URL,但這與觸發'Page.IsPostBack == true'不是一回事。 – Jez 2011-05-31 15:30:15

+0

我明白你來自哪裏。在某種程度上,這是安全的。構建一個POST來僞裝視圖狀態等是困難的,並誘使ASP.NET認爲已經有回發。但是,它可能會被黑客入侵,並且不夠安全。既然讓它更安全就相當容易,爲什麼不這樣做呢? – 2011-05-31 15:44:55

1

你會在和自己的一些討厭的形式的攻擊,如果你沒有在所有情況下檢查;考慮到惡意用戶可以使用所有適當的表單值將HTTP請求構建到服務器上,以使ASP.NET認爲它是回發。我強烈建議檢查每個請求上的用戶角色,回發與否。

+0

沒錯,但我想知道的是,他們建立一組有效的表單值是多麼困難。當客戶端事先不知道頁面GET發生時,ASP.net是否設置了某種回發ID?該機制將阻止'Page.IsPostBack'的惡意觸發器。 – Jez 2011-05-31 15:35:38

3

很容易。它甚至不必通過HTTP發佈。

IsPostBack檢查ViewState和Event * hidden字段。如果在查詢字符串上提供這些字段,則IsPostBack實際上會返回true,因此,例如,嘗試使用該字符串查詢字符串加載圖像的客戶端頁面會導致後面的代碼相信它是回發。

+0

那麼你是不是說只有在'Page.IsPostBack == false'時才檢查用戶的角色是不安全的?因爲,對頁面的第一個請求可能是僞造的回發,如果是這樣的話,我的角色檢查代碼在'Page.IsPostBack == false'塊內將不會運行,因此它將隱藏的功能用戶(作爲用戶沒有權限查看它)會出現? – Jez 2011-06-05 19:49:03

+0

是的 - 無論它是什麼類型的請求,總是檢查角色。 – blowdart 2011-06-06 05:28:28

+0

@blowdart東西剛剛出現在我身上;你認爲在ViewState標誌爲false(或null)時檢查安全權限,然後將該標誌設置爲true會是安全的嗎?對視圖狀態進行評估更加困難,因此如果頁面不是ASP.net回發,視圖狀態應該只會丟失「真正」標誌。 – Jez 2011-06-13 08:57:53

1

因此,正如其他人指出這是一個壞主意,你不應該在你的授權系統中建立漏洞。實際上,授權不應該發生在頁面上,而是在頁面處理之前查看請求的HttpModules中。

要特別回答這個問題,除非您使用ViewState並且設置了唯一的身份驗證用戶的ViewStateUserKey值,那麼很容易讓您的系統認爲IsPostback在沒有時是真實的。它驗證視圖狀態和事件字段,視圖狀態可以僞造。即使使用machinekey加密,也是不夠的,因爲攻擊者可以自己進入頁面,複製加密的viewstate並將其用於惡意攻擊。

在審查,審查如何認證通常在系統中完成,並使用貨架上的東西,而不是手卷。

*編輯*

長的答案:當你在談論安全要打破它的威脅和一一列舉。一旦你瞭解了你的威脅,你就可以從這些威脅中確定你的風險。一旦你有威脅和風險,你可以確定它是否值得減輕威脅,以及如何去做。例如,許多人佩戴安全帶,因爲事故很常見,但我們沒有采取任何措施保護自己免受外來入侵。

你似乎要關心以下威脅:

  • 未認證用戶訪問您的 網站
  • 有些用戶是誰認證,但 不具有所需的權限 看到你的頁面的某些部分
  • Cross site request forgeries

爲了減輕第t請參考標準的現成組件來進行身份驗證,例如FormsAuthenticationModule,它是Forms Authentication的一部分。這些組件都內置在ASP.Net中,設計良好。

一旦用戶對您的應用程序進行了適當的身份驗證,以確定他們是否具有特定的權限,請查看Role Based authorizaton和RoleManagerModule。這將使您有機會將一組角色與表單身份驗證授權的每個身份相關聯。

最後,您可能沒有意識到,但是您已經偶然發現了另一個安全問題,即惡意用戶可能會說服您的應用程序的授權用戶在互聯網的某個其他位置根據您的頁面發生POST 。攻擊者可以在不同的網頁上創建隱藏表單,並使用JavaScript將其提交到您的網頁。如果授權用戶已經登錄,那麼頁面中應該發生的任何操作都將作爲受害者發生,但POST的所有參數都由攻擊者(爲表單及其值編寫代碼)控制。

爲了避免這種情況,最簡單的方法是使用前面提到的ViewStateUserKey值,並確保使用了EnableViewStateMAC或ViewStateEncryption。加密是首選,因爲HMAC只會確保攻擊者不能篡改視圖狀態,但其內容仍可恢復。加密提供機密性和完整性。

+1

我認爲在可能的情況下,在頁面處理開始之前,但是這僅適用於每個頁面。當你希望根據用戶的授權級別來顯示/啓用某些內容時,在代碼隱藏中確實有一定的授權範圍? – Jez 2011-05-31 16:01:21

+1

感謝您的編輯,但它仍然沒有真正解決我感興趣的具體問題。我的問題與您的第二個bulletpoint最接近。我確實使用基於角色的授權,查看我的頁面的用戶確實有角色,我檢查他們以確定頁面上顯示的內容。我的問題仍然是什麼時候我應該檢查這些角色;每頁加載,或者只有當'Page.IsPostBack == false'時。後者是否安全? – Jez 2011-06-05 19:46:40

2

舉一個具體的例子,假設你的頁面有隻有管理員都應該能夠看到並點擊一個按鈕:

<asp:Button runat="server" ID="resetButton" Text="Reset" OnClick="resetButton_Click" /> 

裏面的代碼隱藏的if (!IsPostBack)塊,你躲如果按鈕用戶不是管理員:

protected override void OnInit(EventArgs e) 
{ 
    if (!IsPostBack) 
     resetButton.Visible = IsAdmin(); 
} 

private bool IsAdmin() 
{ 
    ... 
} 

問:一個非管理員可引起resetButton_Click要執行的代碼?

答案:是的,即使啓用了視圖狀態和事件驗證。

有人可以簡單地瀏覽到您的頁面?__VIEWSTATE=?__EVENTTARGET=追加到URL(導致IsPostBack返回true),然後點擊按鈕。

結論:關閉if (!IsPostBack)中的敏感功能並不安全。

要解決此問題,請刪除IsPostBack檢查或將Visible="False"添加到按鈕標記(默認爲安全)。

相關問題