A Matter of Convenience

At this point, you might wonder what you're actually getting with Secure Objects besides some automation. For me, the automation was nice, but the convenience factor is far more important. When you work with the Microsoft-provided validator controls, you often have to combine two or three controls to get complete coverage for each field on a form.

However, having to use two or three controls to perform the job that the SPIValidator does with one is merely inconvenient. The most powerful validator that Microsoft provides is the RegularExpressionValidator. You provide an expression that controls how the user enters data into the field. For example, you can create an expression for a telephone number that restricts the way the user can enter it, to ensure your database receives the correct format. Here's the simple (tongue firmly in cheek) regular expression for US telephone number.

((\(\d{3}\) ?)|(\d{3}-))?\d{3}-\d{4}

Now, imagine trying to write a regular expression for something complex, such as a model number for your company's latest product. Admittedly, Microsoft provides a few common regular expressions including telephone numbers, ZIP codes, e-mail address, URL, and social security number, but you still end up writing this complex code for everything else by hand.

When using the SPIValidator, you click the ellipses next to the AllowPattern property and promptly see the dialog box shown in Figure 5. You can choose any of the standard patterns that the SPIValidator provides, or you can select one that's close to what you need and modify it. The feature I like best is that you can click More and see a test area for the pattern. Type the input to test into the User Input field; the Choose an Allow Pattern dialog box tells you whether the input is accepted.

Figure 6: Creating your own patterns is relatively easy with the SPIValidator.

SecureObjects as Your Only Solution

SecureObjects tends to take over, by making itself your only solution. For example, SecureObjects ignores any Microsoft validator controls that you use. You can secure many textboxes by using a combination of a RequiredFieldValidator (so the user can't skip the entry) and a RegularExpressionValidator (defining precisely what input the user can provide). Because the Secure Form Wizard ignores these controls, you can't be sure that an error is actually caused by the absence of any validation or if the validation you provided was ignored.

After trying the validator controls, I also tried coded solutions. Again, SecureObjects ignores the code that you provide. For example, you could use a combination of data length checks and a regular expression to secure your code, like this.

private void btnTest_Click(object sender, 
                           System.EventArgs e)
{
   Regex   CheckChar = new Regex(@"\w{5}");

   // Verify the string isn't too long.
   if (txtInput.Text.Length > 5)
      throw new ArgumentException(
         "The Input string is too long!");

   // Verfiy the content of the string.
   if (!CheckChar.IsMatch(txtInput.Text))
      throw new ArgumentOutOfRangeException(
         "Incorrect data in the input string!");

   // Show the text in txtOutput.
   txtOutput.Text = txtInput.Text;

   // Make the component visible.
   txtOutput.Visible = true;
}

This code guarantees that no one can enter any special characters as part of the string (making any form of code injection impossible). It also guarantees that the string is precisely five characters long.

Because SecureObjects doesn't consider these other alternatives, you might find yourself reworking code that's already secure. However, SecureObjects still saves you considerable time and effort. Do you really want to take time to learn all of those nifty regular expression-coding sequences? Even if you do, can you be sure they're correct every time? Secure Objects takes the hassle out of security, but you have to use it as your only solution.

A Few Caveats

After installing a product, I always look at the ReadMe file. When working with SecureObjects, you'll be happy you did, too. The ReadMe contains a number of important pieces of information that I won't discuss in depth. For example, you'll find some information about how to display the SecureObjects toolbar if it doesn't install correctly. However, the items that caught my attention immediately were four caveats about using the product — issues that you need to know about before you use this software. Here they are, quoted from the ReadMe file.

The first item is common sense. Checking your application with any security product won't work well unless you have full access to the Web site. Of course, you'll want to perform usability testing with the same rights as your users. That's why it's best to have several accounts on the server, so that you can check the application at different security levels.

The second item is a concern because many companies are developing Web sites that work equally well with desktop browsers and mobile devices today. You can't use SecureObjects as your only testing aid when you want to create dual-purpose applications, and it won't work at all for testing purely mobile applications. According to company representatives, even though SecureObjects doesn't support mobile applications now, they plan to add such support in the future.

The <httpModules> element is important when you create custom modules (DLLs) that perform a special task for all Web pages in an application or an entire machine. For example, you might add a special module to monitor the flow of information or filter unwanted content. However, the use of this feature is somewhat rare and I don't consider it a major issue. Generally, developers use HttpHandlers or the Global.asax file to provide specialized data processing. HttpModules are more suited to defining how ASP.NET processes a request-something you don't need to do very often.

The fourth item can be a concern when you need to mix older and newer technologies within the same Web application. Read this particular caveat carefully-essentially, it tells you that you can't expect much ASP code support. ASP is the script like language that predates ASP.NET. While SecureObjects will do a great job on your newer code, this caveat tells you to check your old ASP scripts for security errors manually.

The Bottom Line

SecureObjects is exceptionally easy to use. The wizards make locating and fixing Web application errors a snap. Technically, the Secure Form Wizard and the SPIValidator aren't doing anything special; you can already perform these tasks using the various Microsoft validators supplied with Visual Studio .NET, or use code to perform the task if you like. However, if you've ever tried to make the Microsoft validators work, then you'll be surprised at the exceptional ease of using the SPIValidator control. What you get is ease of use, which translates into more secure Web pages: developers will actually take the time to secure them.

John Mueller is a freelance author and technical editor. He has writing in his blood, having produced 67 books and over 300 articles to date. The topics range from networking to artificial intelligence and from database management to heads down programming. His most recent book is "Microsoft Windows XP Power Optimization" (Wiley, ISBN: 0764575318).