70-340 Implementing Security for Applications with Microsoft Visual C# .NET Training Course

Demo Question 7.

Answer: B

Explanation: Never Trust User Input!I know this injunction sounds harsh, as if people are out to get you. But many arE. If you accept input from users, either directly or indirectly, it is imperative that you validate the input before using it, because people will try to make your application fail by tweaking the input to represent invalid datA. The first golden rule of user input is, All input is bad until proven otherwisE. Typically, the moment you forget this rule is the moment you are attackeD. In this section, we'll focus on the many ways developers read input, how developers use the input, and how attackers try to trip up your application by manipulating the input. Let me introduce you to the second golden rule of user input: Data must be validated as it crosses the boundary between untrusted and trusted environments. By definition, trusted data is data you or an entity you explicitly trust has complete control over; untrusted data refers to everything elsE. In short, any data submitted by a user is initially untrusted datA. The reason I bring this up is many developers balk at checking input because they are positive that the data is checked by some other function that eventually calls their application, and they don't want to take the performance hit of validating the datA. But what happens if the input comes from a source that is not checked, or the code you depend on is changed because it assumes some other code performs a validity check? NOTE A somewhat related question is, what happens if an honest user simply makes an input mistake that causes your application to fail? Keep this in mind when I discuss some potential vulnerabilities and exploits. I once reviewed a security product that had a security flaw because a small chance existed that invalid user input would cause a buffer overrun and stop the product's Web servicE. The development team claimed that it could not check all the input because of potential performance problems. On closer examination, I found that not only was the application a critical network component-and hence the potential damage from an exploit was immense-but also it performed many time-intensive and CPU-intensive operations, including public-key encryption, heavy disk I/O, and authentication. I doubted much that a half dozen lines of input-checking code would lead to a performance problem. As it turned out, the code did indeed cause no performance problems, and the code was rectifieD. User Input RemediesAs with all user input issues, the first rule is to determine which input is valid and to reject all other input. (Have I said that enough times?) Other not-so-paranoid options exist and offer more functionality with potentially less security. I'll discuss some of these also. A Simple and Safe Approach: Be Hardcore About Valid Input In the cases of the Web-based form and SQL examples earlier, the valid characters for a username can be easily restricted to a small set of valid characters, such as A. Za-z0-9. The following server-side JScript snippet shows how to construct and use a regular expression to parse the username at the server: // Determine whether username is valiD. // Valid format is 1 to 32 alphanumeric characters. var reg = /^[A. Za-z0-9] {1,32}$/g; if (reg.test(Request.form("name")) > 0) { // Cool! Username is valiD. } else { // Not cool! Username is invaliD. }A Regular Expression Rosetta StoneRegular expressions are incredibly powerful, and their usefulness extends beyond just restricting input. They constitute a technology worth understanding for solving many complex data manipulation problems. I write many applications, mostly in Perl and C#, that use regular expressions to analyze log files for attack signatures and to analyze source code for security defects. Regular Expressions in Managed CodeMost if not all applications written in C#, Managed C++, Microsoft Visual Basic .NET, ASP.NET, and so on have access to the .NET Framework and as such can use the System.Text.RegularExpressions namespacE. I've already outlined its syntax earlier in this chapter. However, for completeness, following are C#, Visual Basic .NET, and Managed C++ examples of the date extraction code I showed earlier in Perl. C# Example // C# Example String s = @"We leave at 12:15pm for Mount Doom. "; Regex r = new Regex@".*(\d{2}:\d{2}[ap]m)",RegexOptions.IgnoreCase); if (r.Match(s).Success) ConsolE. Write(r.Match(s).Result("$1"));Visual Basic .NET Example ' Visual Basic .NET example Imports System.Text.RegularExpressions. Dim s As String Dim r As Regex s = "We leave at 12:15pm for Mount Doom." r = New Regex(".*(\d{2}:\d{2}[ap]m)", RegexOptions.IgnoreCase) If r.Match(s).Success Then ConsolE.Write(r.Match(s).Result("$1")) End IfManaged C++ Example // Managed C++ version #using <mscorliB.dll> #include <tchar.h> #using <system.dll> using namespace System; using namespace System::Text; using namespace System::Text::RegularExpressions; . String *s = S"We leave at 12:15pm for Mount Doom."; Regex *r = new Regex(".*(\\d{2}:\\d{2}[ap]m)",IgnoreCase); if (r->Match(s)->Success) Console::WriteLine(r->Match(s)->Result(S"$1"));Note that the same code applies to ASP.NET because ASP.NET is language-neutral. D. Regular Expressions in ScriptThe base JavaScript 1.2 language supports regular expressions by using syntax similar to Perl. Netscape Navigator 4 and later and Microsoft Internet Explorer 4 and later also support regular expressions. var r = /.*(\d{2}:\d{2}[ap]m)/; var s= "We leave at 12:15pm for Mount Doom."; if (s.match(r)) alert(RegExp.$1);Regular expressions are also available to developers in Microsoft Visual Basic Scripting Edition (VBScript) version 5 via the RegExp object: Set r = new RegExp r.Pattern = ".*(\d{2}:\d{2}[ap]m)" r.IgnoreCase = True Set m = r.Execute("We leave at 12:15pm for Mount Doom.") MsgBox m(0).SubMatches(0)\w ----> matches any word character, equivalent to [a-zA. Z0-9] Regular Expressions Regular expressions are a concise and flexible notation for finding and replacing patterns of text. The regular expressions used within Visual Studio are a superset of the expressions used in Visual C++ 6.0, with a simplified syntax. You can use the following regular expressions in the Find, Replace, Find in Files or Replace in Files dialog boxes to refine and expand your search. NoteYou must select the Use check box in the Find, Replace, Find in Files, and Replace in Files dialog boxes before using any of the following expressions as part of your search criteriA. The following expressions can be used to match characters or digits in your search string: The following table lists the syntax for matching by standard Unicode character properties. The two-letter abbreviation is the same as listed in the Unicode character properties databasE. These may be specified as part of a character set. For example, the expression [:Nd:Nl:No] matches any kind of digit. In addition to the standard Unicode character properties, the following additional properties may be specifieD. These properties may be specified as part of a character set. .NET Framework Regular Expressions Provides a brief introduction to .NET regular expressions. Regular Expressions as a Language Provides an overview of the programming-language aspect of regular expressions. Regular Expression Classes Provides detailed information and code examples illustrating how to use the regular expression classes. Details of Regular Expression Behavior Provides detailed information about the capabilities and behavior of .NET Framework regular expressions. Regular Expression Examples Provides code examples illustrating typical uses of regular expressions. System.Text.RegularExpressions Provides class-library reference information for the .NET Framework System.Text.RegularExpressions namespacE. Regular Expression Validator Control Sample The regular expression validator control shown here extends the base validator control described in the Base Validator Control SamplE. This validator adds the following functionality to the base validator: * It exposes a property named ValidationExpression that allows a user (page developer) to specify a regular expression. * It overrides the EvaluateIsValid method (defined as an abstract method in BaseDomValidator) to provide logic to determine whether the field to validate matches the pattern specified by the regular expression. * It overrides AddAttributesToRender (inherited from WebControl) to provide a client-side handler for the evaluation logiC. The client-side handler is a function defined in the script library.