Improving Web Application Security: Threats and - CGISecurity

Chapter 4: Design Guidelines for Secure Web Applications 79In PracticeThe following are examples applied to common input fields, using the precedingapproaches:● Last Name field. This is a good example where constraining input is appropriateIn this case, you might allow string data in the range ASCII A–Z and a–z, and alsohyphens and curly apostrophes (curly apostrophes have no significance to SQL) tohandle names such as O’Dell. You would also limit the length to your longestexpected value.● Quantity field. This is another case where constraining input works well. In thisexample, you might use a simple type and range restriction. For example, theinput data may need to be a positive integer between 0 and 1000.●●Free-text field. Examples include comment fields on discussion boards. In thiscase, you might allow letters and spaces, and also common characters such asapostrophes, commas, and hyphens. The set that is allowed does not include lessthan and greater than signs, brackets, and braces.Some applications might allow users to mark up their text using a finite set ofscript characters, such as bold ““, italic ““, or even include a link to theirfavorite URL. In the case of a URL, your validation should encode the value sothat it is treated as a URL.For more information about validating free text fields, see “Input Validation” inChapter 10, “Building Secure ASP.NET Pages and Controls.”An existing Web application that does not validate user input. In an idealscenario, the application checks for acceptable input for each field or entry point.However, if you have an existing Web application that does not validate userinput, you need a stopgap approach to mitigate risk until you can improve yourapplication’s input validation strategy. While neither of the following approachesensures safe handling of input, because that is dependent on where the inputcomes from and how it is used in your application, they are in practice today asquick fixes for short-term security improvement:●●HTML-encoding and URL-encoding user input when writing back to theclient. In this case, the assumption is that no input is treated as HTML and alloutput is written back in a protected form. This is sanitization in action.Rejecting malicious script characters. This is a case of rejecting known badinput. In this case, a configurable set of malicious characters is used to reject theinput. As described earlier, the problem with this approach is that bad data is amatter of context.For more information and examples of input coding, using regular expressions, andASP.NET validation controls, see “Input Validation” in Chapter 10, “Building SecureASP.NET Pages and Controls.”