Improving Web Application Security: Threats and - CGISecurity

Chapter 21: Code Review 633Do You Secure View State?If your application uses view state, is it tamperproof? Review the followingquestions:● Is view state protection enabled at the application level?Check the enableViewState attribute of the element in the applicationMachine.config or Web.config file to see if view state is enabled at the applicationlevel. Then check that enableViewStateMac is set to “true” to ensure it istamperproof.●●Do you override view state protection on a per page basis?Check the page-level directive at the top of your Web pages to verify that viewstate is enabled for the page. Look for the enableViewStateMac setting and ifpresent check that it is set to “true”. If enableViewStateMac is not present and setto true, the page assumes the application-level default setting specified in theWeb.config file. If you have disabled view state for the page by settingenableViewState to “false” the protection setting is irrelevant.Do you override view state protection in code?Check that your code does not disable view state protection by settingPage.EnableViewStateMac property to false. This is a safe setting only if the pagedoes not use view state.Are Your Global.asax Event Handlers Secure?The global.asax file contains event handling code for application-level eventsgenerated by ASP.NET and by HTTP modules. Review the following event handlersto ensure that the code does not contain vulnerabilities:● Application_Start. Code placed here runs under the security context of theASP.NET process account, not the impersonated user.● Application_BeginRequest. Code placed here runs under the security context ofthe ASP.NET process account, or the impersonated user.● Application_EndRequest. If you need to modify the properties of outgoingcookies, for example to set the “Secure” bit or the domain,Application_EndRequest is the right place to do it.●●●Application_AuthenticateRequest. This performs user authentication.Application_Error. The security context when this event handler is called canhave an impact on writing the Windows event log. The security context might bethe process account or the impersonated account.protected void Session_End. This event is fired non-deterministically and only forin-process session state modes.