5

If you have an SSL certificate for a web site, is it necessary to make the ViewState more difficult to decode. Without any extra development, it appears that ASP.NET encodes it as a base 64 string. I found some sample code to easily decode this hidden field "__VIEWSTATE". Doesn't SSL encrypt this (along with other things) for you?

AviD
  • 72,138
  • 22
  • 136
  • 218
MacGyver
  • 205
  • 2
  • 6

3 Answers3

10

You have to distinguish two kinds of attackers:

SSL is used during transport to prevent a third person from reading and modifying the transmitted data.

The user who sends data to the server and gets answers from the server, can obviously see and modify the data any way he or she wants. So the user can modify the hidden form field containing the view state. Base64 escaping does not offer any protection here, it is just a way to ensure that binary data is not messed up by character set conversations.

So in the likely case that your view state contains trustworthy information, that a malicious user must not modify, you need to enable encryption and signing for it.

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
  • What tools can a user (who gets/sets server data) use to decode this and modify the data? I thought only a proxy (between the server and client/browser) could modify the data before it gets to the browser. Is that incorrect? – MacGyver Aug 04 '11 at 19:21
  • 3
    [Firebug](http://getfirebug.com/), and [Webdeveloper toolbar](https://addons.mozilla.org/de/firefox/addon/web-developer/) are two very common Firefox extensions that allow the life editing of hidden fields within the browser. Of course proxy servers such as Fiddler can be used, too. In this case the malicious users just lets the proxy handle the SSL stuff. – Hendrik Brummermann Aug 04 '11 at 19:46
  • I've used Firebug to modify styles before while the page is being viewed. I guess I never tried modifying other fields before. So what I'm hearing is that you can modify hidden fields while the page is being viewed and submit the form with that change? I definitely have to try this. :-) – MacGyver Aug 04 '11 at 19:59
  • 1
    Actually, if all you want to do is prevent tampering, you don't need to encrypt the viewstate; adding a secure hash is enough. Encryption has the added benefit of hiding the viewstate information entirely though. – tdammers Aug 04 '11 at 20:48
  • 1
    @MacGyver: You don't even know that the user is using a web browser. For all you know, they might use something like curl or wget, or they might even type HTTP commands into telnet. – tdammers Aug 04 '11 at 20:49
  • 2
    @tdammers, the view state might contain information that the user is not allowed to see. For example the user may only be allowed to see aggregated values but the view state might contain the individual items. Another common case is that complete objects (e. g. representing people) are put into the view state and the view only creates html-code for the attributes, the user is allowed to see. One can argue that those filtering task should be done by lower layers, but architecture rules tend to be violated in huge projects. – Hendrik Brummermann Aug 04 '11 at 21:30
  • So I realize the purpose of the viewstate is to keep track of values in the form so that during a postback, you don't lose track of data. Despite what happens to the values in the viewstate that are not normally visible in actual controls/fields on the form, what actually takes the values out of the viewstate and puts the values into the fields? Is the browser doing that or is the server doing that just before sending the rendered HTML? I'm guessing the browser can't do much more than interpet HTML, right? So if I use the hash, the server only has to understand it, right? – MacGyver Aug 05 '11 at 03:18
2

"Encrypt" is different than "encode". BASE64 is not an encryption algorithm.

ViewState contains "binary" information -- information that is more than simple text. Since you cannot (or should not) have binary information the HTML META tags or HTTP cookies, the binary data has be encoded in a text format. BASE64 encoding is a popular choice, so is simple hex encoding.

Note that the ViewState variable is also ASN.1 encoded. It contains numerous, variable length fields, which are "tagged" with type information and length encoded.

Inside all that, the ViewState variable contains cryptographically secure information, such as session IDs, that are resistant to tampering, so that hackers cannot manipulate one person's session IDs in order to hack into somebody else's session. That's why you see ViewState decoders out there: sometimes website operators don't use the right cryptographic primates, and expose the Viewstate internals to manipulation by hackers.

As other responses have said, SSL only encrypts the traffic on the network wire, so that people cannot eavesdrop on it. Obviously, it has to be decrypted on your side so that your browser an render the page, and on the server side when it creates the page.

Robert David Graham
  • 3,883
  • 1
  • 15
  • 14
  • 1. Viewstate is not a meta tag, nor is it a cookie: it's a regular hidden form field. 2. Unless your server code is doing something hinky, there is no reason a session id would be in the viewstate. Other than those points, though, good answer :) – AviD Aug 08 '11 at 06:48
0

ASP.NET 2.0 or later also sends a MAC key which acts as a hash and helps prevent tampering, see this page for details. That sets the barrier to attack a bit higher than just messing with a base64 encoded string.

Wyatt Barnett
  • 297
  • 1
  • 5
  • 2
    *"sends a MAC key"* - That isn't quite right. Rather, the server protects the view state from tampering with a Message Authentication Key (MAC), by computing a keyed "checksum" of the data and appending this checksum. The key (the MAC key you are referring to) is kept secret by the server and is never sent to the client. It is used by the server to append a checksum on view states going to the client, and to check the checksum on view states coming back from a client. – D.W. Aug 05 '11 at 05:50