Improving Web Application Security: Threats and - CGISecurity

74 Part II: Designing Secure Web ApplicationsAlso consider identity flow and identify the accounts that will be used for networkauthentication when your application connects to remote servers. A commonapproach is to use a least privileged process account and create a duplicate (mirrored)account on the remote server with the same password. Alternatively, you might use adomain process account, which provides easier administration but is moreproblematic to secure because of the difficulty of limiting the account’s usethroughout the network. An intervening firewall or separate domains without trustrelationships often makes the local account approach the only viable option.Intranet, Extranet, and InternetIntranet, extranet, and Internet application scenarios each present design challenges.Questions that you should consider include: How will you flow caller identitythrough multiple application tiers to back- end resources? Where will you performauthentication? Can you trust authentication at the front end and then use a trustedconnection to access back-end resources? In extranet scenarios, you also mustconsider whether you trust partner accounts.For more information about these and other scenario-specific issues, see the“Intranet Security,” “Extranet Security,” and “Internet Security” sections inthe “Microsoft patterns & practices Volume I, Building Secure ASP.NETApplications: Authentication, Authorization, and Secure Communication”at http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp.Input ValidationInput validation is a challenging issue and the primary burden of a solution falls onapplication developers. However, proper input validation is one of your strongestmeasures of defense against today’s application attacks. Proper input validation is aneffective countermeasure that can help prevent XSS, SQL injection, buffer overflows,and other input attacks.Input validation is challenging because there is not a single answer for whatconstitutes valid input across applications or even within applications. Likewise,there is no single definition of malicious input. Adding to this difficulty is that whatyour application does with this input influences the risk of exploit. For example, doyou store data for use by other applications or does your application consume inputfrom data sources created by other applications?The following practices improve your Web application’s input validation:● Assume all input is malicious.●●●●Centralize your approach.Do not rely on client-side validation.Be careful with canonicalization issues.Constrain, reject, and sanitize your input.