Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 4 down vote favorite
1

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?

share|improve this question

3 Answers

up vote 8 down vote accepted

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.

share|improve this answer
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 4 '11 at 19:21
3  
Firebug, and Webdeveloper toolbar 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 4 '11 at 19:46
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 4 '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 4 '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 4 '11 at 21:30
show 2 more comments
up vote 2 down vote

"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.

share|improve this answer
Thanks for clarifying that. – MacGyver Aug 5 '11 at 3:03
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 8 '11 at 6:48
up vote 0 down vote

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.

share|improve this answer
1  
"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 5 '11 at 5:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.