2013-10-15 99 views
0

環境安全解決方案的ViewState MAC驗證失敗

好了,所以我想在這裏不創建一個重複的,但我意識到這個問題已經被排序的前處理。

我已經做了一堆閱讀上的錯誤:

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

我開始的錯誤之後,我們升級了網絡監控軟件和SQL版本。

該頁面是一個ASP.NET 4.0 web表單,它用來顯示在網站外部,用C#語言編寫,帶有一點JavaScript和一點SQL。它還大量使用.NET的圖表形式(如圖表上的六個圖表區域,每個圖表都有通過SQL動態生成的多個系列)。我們從SQL Server 2008R2的免費版本開始試用完整的SQL Server 2012實例,並將我們的SolarWinds Orion版本更新爲NPM 10.6。

該代碼是一個大型圖表程序,用於跟蹤我們每個網絡上平均的各種統計數據的健康狀況。問題是,他們要求提供自動更新的'滾動圖表'。我正在使用表單刷新而不是元數據或完整回發,因爲有各種各樣的變量允許圖表停留在特定的統計信息,網絡,頁面和時間窗口中,以便當用戶離開它時,它將刷新並保持他們最初查看的視圖。如果不超過5分鐘,它會不斷更新。所有這些值都存儲在ViewState中。 (最初更糟糕的是,它被存儲在頁面上的隱藏文字中)。

更新軟件並沒有神奇地將它變成網絡農場或羣集,我們沒有虛擬環境,儘管我們可能會很快。

研究

我理解這個問題是由ViewState中不方便時刷新,並導致關鍵的驗證失敗造成的,因爲在頁面加載了與驗證算法同步。我見過很多類似的問題和答案像這樣的:

ASP.NET Validation of viewstate MAC failed

Validation of viewstate MAC failed when on page for 20+ minutes

ScriptResource error: am I being hacked?

http://aspadvice.com/blogs/joteke/archive/2006/02/02/15011.aspx

誠然,這是不面對客戶,但每微軟:

This attribute should never be set to false in a production Web site, even if the >application or page does not use view state. The view state MAC helps ensure the security >of other ASP.NET functions in addition to view state.

我的問題:

所有這些問題的答案似乎有相同的解決方案,我不相信這些都是很好的解決方案。我有什麼替代方案?我的上司,我不認爲從安全的角度來看,關鍵是好的。我願意調整代碼以存儲其他方式。我不得不在其他地方使用會話狀態,但我仍然對它不熟悉。在進行某種驗證之前,會不會出現與刷新類似的問題?我可以強制更新運行更慢嗎?我也看到了一些關於改變密鑰驗證發生的地方。從安全的角度來看,這個解決方案如何?

回答

0

首先,我終於找到了我的錯誤。事實證明,我實際上正在設法創建SQL Server死鎖,這反過來意味着我的.Net圖表正在拋出一個未處理的NullReference異常(derp)。

好的,所以,在ASP.NET中只有幾個alternatives to ViewState。我終於讓我的頁面工作了,所以我將這裏留給任何隨機發生的任何人。

一個你在這裏看到的這樣的替代品是剛剛set the machine key並啓用MAC狀態,像這樣:

<pages enableViewStateMac="true"> 

然後:

<machineKey 
    validationKey="[128 Hex Number]" 
    decryptionKey="[64 Hex Number" 
    validation="SHA1" 
    decryption="AES" /> 

我是適度關心這個安全原因,但我無法做出任何其他解決方案的工作。我最終得出的結論是,我只是靜態設置,並重新生成基於Microsoft's example code正規的機鍵:

static void Main(string[] argv) 
    { 
     //128 Hex characters for the validation key, 64 for the AES decryption key 
     int hexLengthForEncryption = 128; 

     string validationKey = Generate_New_Key(hexLengthForEncryption, argv); 

     hexLengthForEncryption = 64; 

     string decryptionKey = Generate_New_Key(hexLengthForEncryption, argv); 

     string[] originalKeys = new string[2] {validationKey, decryptionKey}; 

     Generate_File(originalKeys); 

     Console.WriteLine("The file has been generated. Would you like to generate new keys in a new file?"); 

     string yorn = Console.ReadLine(); 

     while ((yorn != "N") && (yorn != "n") && (yorn != "no") && (yorn != "No")) 
     {    
      hexLengthForEncryption = 128; 
      validationKey = Generate_New_Key(hexLengthForEncryption, argv); 
      hexLengthForEncryption = 64; 
      decryptionKey = Generate_New_Key(hexLengthForEncryption, argv); 

      string[] freshLines = new string[2]{validationKey, decryptionKey}; 

      Generate_File(freshLines); 

      Console.WriteLine("The file has been generated. Would you like to generate new keys to a new file?"); 

      yorn = Console.ReadLine(); 
     } 
    } 

這並不能完全解決我的問題,雖然。我最終做的是,對於有查找頁面的圖表,我在我的大型SQL查詢中添加了一個try catch,儘管reservations from posts like thisWITH(NOLOCK) on Stack Overflow類似的問題,我們決定可能的陷阱落在可接受的誤差範圍內。

在實際關心會話ID的頁面中,我不得不強制程序暫停並返回查找頁面。有趣的是,它完全沒有崩潰,我登出後每隔兩分鐘就刷新一次圖表。不使用會話ID仍然是頁面有一個扔掉的變量設置這樣的主網頁:

protected override void OnInit(EventArgs e) 
    { 
     base.OnInit(e); 
     ViewStateUserKey = Session.SessionID; 
    } 

這在控制的解決方案正常工作:

 //This variable is necessary to having a session state persist across postbacks, but is otherwise useless 
     Session["Throwaway"] = DateTime.Now; 

此頁面上的捕捉只是重定向回自己。具有搜索頁面的頁面導致參考循環問題,因爲會話狀態(頁面依賴於生成圖表)是空的,因此打破了圖表。我不知道這對任何人都有幫助,但是使用會話狀態的圖表和那些不需要它的圖表在網絡升級後終於可以工作。乾杯!