ASP.NET Viewstate - seeking clarification about a support article

Question

Just looking to see if anyone can explain this further.

In support article 829743 on microsoft.com, they say:

If you turn the view state MAC feature off, and then you use view state for controls that do not HTML encode (for example, a Label control), attackers can tamper with the view state data and can put arbitrary data in view state. This arbitrary data is decoded and then used by controls when they render the posted page. As a result, attackers can inject script into the application unless you work to prevent the attack. For example, an attacker could decode the data, inject script into the data where a Label control is, and then link to it from a Web site. Anyone who clicks on the link would be the victim of a script injection attack that could potentially steal their authentication cookies or session id. The script could also let an attacker alter state data for controls that use view state and application specific attacks could occur as a result.

This makes no sense to me. Why would a label control, or any other static control that never changes and doesn't engage with http request data, need viewstate? I thought only form controls would use viewstate. Is there something I'm missing? If the label control uses viewstate, then that's messed up, IMHO. Just looking for clarification if anyone can shed some light. Maybe it's not late enough or I haven't had enough beer yet. Thx!

score 0 · Accepted Answer · edited May 23 '17 at 10:25

Why would a label control, or any other static control that never changes and doesn't engage with http request data, need viewstate?

First of all viewstate have the Literal, the Label and other controls and use it by default, unless you turn it off for that controls using the EnableViewState="false".

Some reason that I can think of using the viewstate is the caching/saving/keeping the same data for the next post back. Eg. This code will keep the text inside the literal after the post back without setting it again.

<asp:Literal runat="server" EnableViewState="true" ID="txtLiterar">

protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        txtLiterar.Text = "Time of start editing:" + DateTime.Now.ToString();
    }
}

After the post back the control will keep the fist init value.

Why the EnableViewState is on by default, well, you can see the controls as variables that you set your data on code behind and you need to have it again after the postback. Or else why to use controls ? type it directly to the page.

On the other hand, if you understand what you do, and how they work you can turn the viewstate off on most of them - and set them again on the post back.

In this answer I have write some more about the viewstate and where is needed most: How I can deactivate ViewState without Control problems

Now lets go back to the real issue, the security.
If you turn off the validation of the viewstate, now the text that is used for the Literal, is also saved on the viewstate.

Any one can read it and change it (if you do not have secured it) and lets say that change the text

"Time of start editing", to "<script>alert("hello there");</script>", now on the first post back the Literal will render the script and here is the issue that is warning you about.

Thanks, David! That perspective helps clear it up! I tend to focus on serving HTTP requests in my web apps and less on the (what I consider bloat) ins and outs of .NET. Hence, my confusion. I hadn't thought of that as an attack vector before, not looking at how the control gets its value from a .NET perspective. Thx again! — Scott, Jun 01 '13 at 05:25
@Scott Look at the text above the icons, Aristos is answering, David correct a small type mistake. — Aristos, Jun 01 '13 at 10:22

ASP.NET Viewstate - seeking clarification about a support article

1 Answers1