I watched a talk recently ( http://vimeo.com/68390507 ) where the speaker is very serious, saying several times, to never set EnableViewStateMac=false.
While using Enterprise Web Library, I noticed that EnableViewStateMac is set to false. What is being done in EWL to make up for this? How can I trust that it's secure?
It's important to note that while EWL currently has a dependency on Web Forms (and view state), it is a weak dependency, and our roadmap calls for eliminating the dependency entirely. EWL completely overrides the saving and loading of view state by using Page.SavePageStateToPersistenceMedium and Page.LoadPageStateToPersistenceMedium, and this means that it is impossible for any controls on the page to store their own [possibly insecure] state.
Here's the complete list of what EWL stores in view state:
EWL "page state". This is data that needs to persist for as long as a user stays on a page, but shouldn't be stored in a database or other durable storage. For example, the current item display limit of an EwfTable, or a form field value that needs to be saved on an intermediate post-back so that parts of the page can be refreshed. This type of data is directly manipulated by the user and not any more secret than run-of-the-mill form field values. In fact, we're considering storing it even more openly in hidden fields, which will enable JavaScript to manipulate it without post-backs.
A "form value hash". This is a hash of all form field values at the time the page was rendered. It is used on post-back to inform the user if any of the data changed under their feet since the last time they loaded the page. If this hash is hacked, two things could happen. First, the user could receive a "concurrency error" even if no data changed. Second, the user could not receive a concurrency error even if data did change. This second case may sound bad, but keep in mind that most web applications in the wild do not even have this type of concurrency checking in the first place.
The ID of the data-modification that failed on the last post-back. This is either null, empty, or equal to one of the post-back IDs present in the HTML of the page, and is used to re-run a data modification in certain cases, in order to re-display validation errors. The worst hacking outcome is that a different, but still triggerable, set of validation errors gets displayed.