Security Bulletin: View State Security

Effectively managing user state in Web applications requires a delicate balance between performance, scalability, maintainability, and security. Security considerations are extra important when managing the user state stored on the client. One of my colleagues once said that processing client-side state data is like handing the ice cream to a 5-year-old: You can get the ice cream back, but you can't expect the ice cream shape to be the same as when you get it back!

In this month's column, we will explore some of the security risks around the client state management in the ASP.net application, with particular attention to view state security. (Note: This article assumes that you are familiar with the concept of ASP.net view state.) ）。

If you think that any data stored in the view state of your application is not worth protecting, think again. Sensitive information can even enter view state when you are not aware of it. Even if you are wary of taking measures to prevent sensitive information from being lost through view state, an attacker can still tamper with view state and even cause you and your users greater trouble. Fortunately, ASP.net has some built-in defense components to defend against these attacks. Let's take a look at how to properly use these defense components.

Threat 1: Information disclosure

At Microsoft, the development team uses the STRIDE model to categorize threats. STRIDE is the initials, respectively, representing:

Fake

Tamper

Deny

Information disclosure

Denial of Service

Elevate permissions

The two main STRIDE categories involved in view state security are information disclosure and tampering (a successful tampering attack can lead to elevated privileges, which we will discuss in detail later). Information disclosure is relatively easy to explain in these threats, so let's start with it.

One of the most regrettable and common misconceptions about view state is that it has been encrypted or otherwise handled and cannot be read by the user. After all, the view state string does not seem to be decomposable:

<input　type="hidden"　name="__VIEWSTATE"　id="__VIEWSTATE"　 value="/wEPDwULLTE2MTY2ODcyMjkPFgIeCHBhc3N3b3JkBQlzd29yZGZpc2hkZA=="　/>

However, this string is only base64 encoded and does not employ any powerful cryptographic algorithms. We can easily decode and deserialize the string by using the Restricted object serialization (LOS) Formatter class System.Web.UI.LosFormatter:

LosFormatter　formatter　=　new　LosFormatter();
object　viewstateObj　=　formatter.Deserialize ("/wEPDwULLTE2MTY2ODcyMjkPFgIeCHBhc3N3b3JkBQlzd29yZGZpc2hkZA==");

With a quick look at the debugger (see Figure 1), you can see that the deserialized view state object is actually a series of System.Web.UI.Pair objects that contain the value "password" and the corresponding string value "swordfish" The end of the System.Web.UI.IndexedString object.

Figure 1 The secret view state data revealed by the debugger

If you're not going to bother writing code to deserialize the view-state object, there are several handy view-state decoders available on the Internet, including Fritz Onion's ViewState Decoder tool, which is: Alt.pluralsight.com/tools.aspx.