1

I've read a lot about ViewState on MSDN and looked at these questions (among others):

I see that if you have EnableViewStateMac turned on, ViewState is signed with a calculated value called a MAC to detect if it's been tampered with during round-trips, and ASP.NET will throw an exception if it detects that the MAC does not match the client's ViewState data.

To me, this means that it is safe unless the private key used to sign the ViewState is somehow reverse-engineered, similar to how SSL cryptography works. Hopefully this is true, but correct me if it's not. I might be missing another piece to how ASP.NET works internally, but it seems to me that you should be able to rely on a control's state to control program execution and flow, since the only way to modify the control's state is in server code based on a postback containing valid changes to the client's form.

The question is: Practically, is it okay to use a control's state (if it is not supposed to be changeable by the user) for programmatic decisions, and what are the possible dangers and how could those cause a practical problem?

Here are two specific examples of what I'm wondering is safe from bypassing via ViewState tampering (this is a mock-up of what I'm doing):

Example 1

Public Sub SetPageState()
    If User.IsLoggedIn() Then
        MultiView1.ActiveViewIndex = 0 'user is logged in
    Else
        MultiView1.ActiveViewIndex = 1 'user is not logged in
    End If
End Sub

Private Sub PersonalizePage()
    If MultiView1.ActiveViewIndex = 0 Then
        'Do logged-in stuff
    ElseIf MultiView1.ActiveViewIndex = 1
        'Do not-logged-in stuff
    End If
End Sub

Example 2

Public Sub SetUserLoginControl()
    Label1.Visible = User.IsLoggedIn()
End Sub

Private Sub DoLoginThings()
    If Label1.Visible Then
        'Do logged-in stuff
    Else
        'Do not-logged-in stuff
    End If
End Sub

I realize the "correct" way would be to check for User.IsLoggedIn() (or whatever needs checked) in every place where that's what is supposed to be controlling it, but in some cases the function is computationally expensive, and it's much cheaper to check the state of a control that was modified based on the return value of the expensive function. I realize there are ways around this, such as storing a temporary copy of the function return value, etc., but this is more of a conceptual question than a "here's my problem, now solve it for me" question.

Community
  • 1
  • 1
Oran D. Lord
  • 697
  • 1
  • 9
  • 23

1 Answers1

0

Your code when using controls is unreadable which is bad. You might want to cache state of User.IsLoggedIn() in HttpContect.Current.Items dictionary. It's somewhat a cache that lives for a single request only.

Migol
  • 8,161
  • 8
  • 47
  • 69
  • I edited the code to make it more clear what's going on. – Oran D. Lord Mar 19 '14 at 01:17
  • @OranD Lord: you didn't understand me here - your code won't be readable for other people or you after few months. – Migol Mar 19 '14 at 01:26
  • Maybe you didn't understand me. I'm asking whether using a control's state for program control is a security risk. As stated in the last paragraph, I'm not interested in possible alternatives. – Oran D. Lord Mar 19 '14 at 16:48