I read this somewhere:
"Because the view state for a given page
must be kept ON THE SERVER, it is possible for the current
state to be out of synchronization with the current page of
the browser, if the user uses the Back feature on the
browser to go back in the history"
I suspect that this may not be the default setting but instead an option to store the viewstate on the server, as what would the point of storing the ViewState in the page AND the server be? Am I correct?
If ViewState is stored on the server, how does one avoid the BackButton isue described here?
ASP.NET ViewState is stored in the client in one (or more) hidden HTML input field. I'd be really interested in seeing where you read that incorrect statement.
The server totally forgets ViewState once sent. As a security measure against tampering, ASP.NET can encrypt it and validate it against its key. If you use a set key (rather than auto-generating one), that view state will be valid even if the server has been shut down and rebooted entirely. All which illustrates that nothing in view state is stored on the server.
Related
I'm currently working on an asp.net application which makes use of a user system
and I was curious about how data was actually sent towards the server from the client.
It appears that the information which is being sent can be easily traced because it isn't encrypted into a hashcode or anything. It's plain ordinary text.
I've used an application called "SocketSniff" for reading the data.
The data sent back appears to be stored in the scriptmanager using the element ID and its value.
Do you know any way to avoid the scriptmanager from showing element contents?
I'm guessing it has something to do with the ViewState but this didn't work at all.
I'm not a security specialist but encrypting sent data and the viewstate are two different things.
When you send data over the internet not only the data from your webform is send but, the entire webform is send back to the server. (not using javascript / AJAX) this is only encrypted if you use a certificate. You can easily buy one and it does not have to be expensive. Please note that when you debug the page in Google Chrome (data will appear not to be encrypted) it gets encrypted in the background when you send it.
The viewstate is used for storing data and preventing page forgery. It’s not 100% bulletproof. But if the page is not very interesting for a hacker (the effort often isn’t worth it) I don’t think your building the webapplication for the FBI, CIA or an International Bank so don’t worry about that. When you alter a page “HTML” and add values to elements that can not have a (specific value). Id’s for example. IIS finds a forgery. IIS send a page with Id 123 and get a forged page back with Id 456 in a specific element. Withoud a vieustate this could lead to a CRUD (Create, Retrieve, Update or Delete) operation. Now IIS sees the forgery and gives an error to the user.
Hope it helps.
I am quite new to WebForms and I'm trying to understand the ViewState. AFAIK today, it keeps modifications of the UI over postbacks to the same page. But why does it send the state (= stored modifications) to the client and does not keep it on the server saving CPU cycles and bandwidth?
Am I understanding something completely wrong?
The view state is something intrinsically connected to the view, as the name implies, and trying to manage it separately while maintaining that relation is not something that is easily accomplished.
You would need to store view state per page, so you would still have to send to the client an ID in order to be able to get the correct view state on a postback. Another serious issue is that you send a page to the client but you don't know when or if the client is going to postback that page to the server, so you would need to store view state at least until the session expires.
This could lead to a waste of server resources, as all those view states are being stored for users that may never postback to the server. If you keep your view state slim you'll agree that the best place to store it is to send it with view.
Finally, if you're still not happy with the view state on the client you can override the SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium methods of the page and save it to another medium. I've already heard many people complain about view state on the client, and most time I just tell them to go ahead and implement persistence to another medium on the server... however, I believe no one ever did, probably because it's complicated and you'll end up with a solution that's not that clean.
ViewState is used when a page performs a post back in order to restore the control tree of the page to what is was when the page was last rendered.
This allows for instance a GridView control to keep it's state (what is shown in the GridView) on post back without having to rebind it to the same data.
The reason why the ViewState per default is serialized and sent to the client is (I guess) that it's the easiest way to get it back when the client performs a post back.
What if for instance a user has several browser windows open with the same page loaded and you have the viewstate stored in the Session? Assigning the correct viewstate to the different windows in such a case can of course be solved, but having the client explicitly post it seems to be the easiest way.
That said, it is possible to have the viewstate stored in the Session. See for instance this link.
Other possibilities are available by implementing your own System.Web.UI.PageStatePersister.
Where is a ViewState Stored? Is it stored in Server or Client Side?
I have a huge data which should be stored for some process. I was using Session. But when moved from one page to another im not able to clear the session. So I thought of implementing ViewState. But when running with huge amount of data ViewState is throwing error?
How can I resolve this?
Viewstate is stored on page it self in encoded form. You can't access the viewstate in client side in a direct manner. You need to know the encoding/decoding algorithms to fetch the valuable data from this viewstate in clientside code.
You can use hidden variable to store data that will be used only on that page. Hidden variables are accessible from client side and server side code.
You can use Cache or session to store datatable (large data). They will have good performance as compare to ViewState.
The Cache is always using the machine's memory, the Session uses what has been configured:
In a web farm the Session can be local (which works only if affinity is set), or remote (state server or database, or custom), but the cache is always local.
So, storing a DataTable in the cache will consume memory, but it will not use serialization.
PS: storing a DataSet instead of a DataTable will change almost nothing.
Refer Cache Implementation
The ViewState is not stored on either side, it's send back and forth between the server and the browser on every request and response, so it's not a good idea to put a huge amount of data in ViewState.
ViewState is stored where you tell it. By default, this is in a hidden field on the page sent to the client.
ASP.NET can also store ViewState inside the Session, i.e. on the server, if you tell it to.
Save large amount of data in view-state slowdown your site.
Use query string to fetch fresh copy from database on each page rather than save whole information from previous page.
View State Information stores in hidden fields.
Information travels between server and client in this hidden fields.
For asp.net control,.. by default .net implements view state for all its control, thats why a textbox value does not lost when we click on a button of that page.
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. By the way, the page involved will be using SSL.
Is this safe?
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.
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.
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.
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/
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.
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.
Please anyone explain me the difference between ViewState,Application and Session of a Page ?
Quick one liners - if you want more detail, just ask
ViewState is the variable that holds the current state of the page, which is held in a hidden field in the page (used frequently)
ApplicationState is a variable you can store values in during the life off the application (may get cycled periodically, and without your knowledge) (used less-frequently)
Session is the variable you can write to that will persist from the moment they hit your site until they close the browser. (barring any timeouts). (used frequently)
A great article :
How to Choose From Viewstate, Session, Application, Cache, and Cookies
Some good discussion about the difference between Session and Viewstate : Session Vs ViewState
Session state is saved on the server.
Session state is usually cleared after a period of inactivity from the user.
Can be persisted in memory, which makes it a fast solution. Which means state cannot be shared in the Web Farm/Web Garden.
Can be persisted in a Database, useful for Web Farms / Web Gardens.
Is Cleared when the session dies - usually after 20min of inactivity.
ViewState is saved in the page.
The view state is posted on subsequent post back in a hidden field.
Is sent back and forth between the server and client, taking up bandwidth.
Has no expiration date.
Is useful in a Web Farm / Web Garden
SESSION Variables are stored on the server, can hold any type of data including references, they are similar to global variables in a windows application and use HTTP cookies to store a key with which to locate user's session variables.
VIEWSTATE Variables are stored in the browser (not as cookies) but in a hidden field in the browser. Also Viewstate can hold only string data or serializable objects.
When we use view state to design a web application it retains it's state consistently, in it's current position. If we use session then it does not retain it's state, so when we refresh the browser it starts from the initial page.