Is it safe to store credit card and pricing information in ViewState even over ssl?

Question

The Title pretty much says it all but to clarify more I have a page with private properties that are storing a credit card object and a shopping cart object in viewstate so I can maintain a reference to them across postbacks. BTW the page involved will be using ssl. Is this safe? Thanks!!!

Answer 1

Hi Mike, I would say definitely not, If you are needing to store Credit card details across multiple Http requests i would possibly have a rethink about your architecture.

Hope this helps.

Answer 2

I wouldn't store sensitive information in viewstate ... ever. By doing so, you are delegating security to the implementation of the browser for protecting your customers' data. Vulnerabilities like cross-site scripting (XSS), URL-redirection attacks, and so on could expose this sensitive data to intrusion, theft, or spoofing.

If you are storing such details across postbacks, you should re-evaluate your design - and find a way to avoid doing so.

Answer 3

Viewstate is hackable. If you need to store that info across postbacks, look into storing it in an encrypted database.

EDIT (for the down voter):

Q10. Is ViewState secure by default? Can it be secured? How?

By default, the value of the __VIEWSTATE hidden form field is Base64 encoded and not encrypted. Hence, by default data in ViewState is not secure.

Yes, data in the ViewState can be secured. There are two things that may be done. The first is to use SSL. The second is to ensure that EnableViewStateMac is set to true. This will ensure that the ViewState will be encrypted and also checked against tampering. The default encryption algorithm is SHA1 but it can be changed to MD5 or 3DES, if desired. That said, one should bear in mind that there is almost always a trade-off between increased security and performance. It is best to avoid storing sensitive data in the ViewState and incurring the performance penalities due to the need to increase security.

page link

Remember that anything contained in the ViewState is being delivered to the client browser (simply stored in a hidden input), and is being passed back and forth from client to server. Encrypting and Decrypting data can be a huge system overhead.

Answer 4

All the other answers seem to imply that viewstate is completely insecure. I don't agree with that.

ASP.NET can encrypt the viewstate with the server's key. If you do that then in theory it should be safe enough. Having said that, I still don't recommend it. Someone else will come along one day and disable the encryption "for testing purposes" or set a weak key or the server's config file will be compromised somehow and suddenly your credit card numbers are vulnerable.

So yes, there is a measure of security in viewstate, but there are still better ways of doing this. Even storing sensitive data in the user's Session would be much better and quite simple to do.

Answer 5

I Wouldn't recommend it and really think over my design if i ran in to it. But if you want to do it: store the viewstate on the server.

Read this: http://aspguy.wordpress.com/2008/07/09/reducing-the-page-size-by-storing-viewstate-on-server/

Answer 6

Few points

• MSDN: (Session vs ViewState) While the ViewState data is encoded and may optionally be encrypted, your data is most secure if it is never sent to the client. So, Session state is a more secure option. (Storing the data in the database is even more secure due to the additional database credentials. You can add SSL for even better link security.) But if you've displayed the private data in the UI, presumably you're already comfortable with the security of the link itself. In this case, it is no less secure to put the same value into ViewState as well.

• ViewState is Visible in Source : Although freely accessible in a hidden field called __VIEWSTATE, the view state information is not clear text. By default, a machine-specific authentication code is calculated on the data and appended to the view state string. The resulting text is then Base64 encoded only, but not encrypted. If data confidentiality is desired, however, then SSL is the only solution since it protects not only view state, but all the data that travels to and from the page. Decoding view state is still possible, but a number of steps must be accomplished; not only must several undocumented and internal structures be disassembled, but a number of circumstances must also occur. In addition, consider that a tampered view state is normally detected on the server and a security exception is thrown. Finally, and most important of all, the view state contains data, not code. Unless you explicitly lessen the default security settings for the page, there's not much a hacker can do to modify the view state. If you change the default security settings, though, you should be careful about the view state. A hacker could modify the data that represents the state of the page. This is not a bug per se and opens holes for attacks only if the basic rules of data validation and data checking are not enforced. But this, you understand, is a more general problem when you're trying to write secure code. The view state internal implementation is quite complex and layered enough to discourage attacks. Encryption is the most important element in protecting view state information. In order to make the view state more secure, the ASP.NET @Page directive supports an attribute called EnableViewStateMac whose only purpose is detecting any possible attempt at corrupting original data.

• If EnableViewStateMac is True, then when the page posts back the encrypted view state is algorithmically checked to verify that it has not been tampered with on the client. The net effect is that you might be able to read the contents of the view state, but to replace it you need the encryption key, which is in the Web server's LSA.