Chapter 26: Securing Your Web Application

SECURITY IS ONE OF THE most important features of any Web application. ATL Server is designed for high-end Web applications and services, and these mission-critical applications almost always require mission-critical security.

This chapter will introduce you to some of the key requirements in securing a Web application, and it includes an examination of some of the security support provided by ATL Server. Unless you re already an expert in security, however, we recommended that you buy a book devoted to the topic. Creating secure applications on any platform requires a significant amount of thought and effort, and Windows is no exception. The Windows security- related APIs have many semantics that the average developer may not be aware of.

Security Best Practices

We start this chapter by discussing some of the best practices you should follow when creating secure applications. Some of these are techniques that we used in creating the ATL Server library itself, and others are techniques that we recommend developers take advantage of when creating end- user applications. Many of the suggestions in the following list may seem like common sense, but they re items that time and time again application developers forget.

• Analyze threats: Security is difficult and, as with any difficult process, you re best off spending your time where it s most effective. With security, you ll want to spend most of your time focusing on the most vulnerable areas of your application. The only way to do this is to complete some level of threat analysis on your application. Threat analysis should involve documentation of the findings and should point out all possible threats. Ranking these threats by priority is a secondary task after identifying possible methods of attack.

• Check errors: One of the most common mistakes that application developers make is not checking for errors (either in return values or via exceptions) from their calls. If an API can return an error, then there are situations where it can fail. Unless you understand the implementation of the API completely (including all semantics), it s best to check for errors and respond appropriately. Having your application terminate is better than giving control over to a hacker!

• Use tools: Two categories of tools are very useful for securing your application. The first category of tools is stress tools. Reliable applications tend to be secure applications because they handle unusual situations (e.g., stress) safely. Testing your application in stressful conditions (e.g., low memory) is a good way to see if you re checking for uncommon API failures (there are some great tools that simulate OS API failures for you). It s very possible that your server will hit these conditions, or that a hacker can figure out a way to make your server enter into these conditions. Compiling /GS and using tools such as BoundsChecker and PC-lint can help improve the quality of your code, which in turn can help make it more reliable and more secure. The second category of tools is hacker tools. A number of Web sites are devoted to hacking and hacking tools. Even if you can t or don t want to play around with some of these tools, you should consider using tools such as Perl to create attack scripts and testing if various threats are exploitable. You should create some template Perl scripts so that it s easy for team members to test the scenario that they re interested in without having to put together the entire request packet.

• Use secure functions: Sure, you use the security APIs, but do you make calls to CRT functions such as strcpy or sprintf? Many of these APIs have no validation whatsoever, and you re often better off using the safe versions of these function (e.g., strncpy , shlwapi.h, or strsafe.h in the platform SDK). CFixedString has better performance characteristics than String in many situations, but both provide more security than many custom string classes or char * . Using these functions eliminates many of the most common buffer overrun bugs in code.

• Perform code reviews: The best way to test for security is to perform code reviews. These reviews should include individual reviews as well as group reviews. Although reviewing an entire code base is always ideal, it s often unrealistic . For this reason, you should pay attention to high-risk areas (once again, the threat analysis comes in handy). Following all user input from when it s received to when the request is complete is critical to any application. You should also look at what happens when invalid requests are sent to your application (invalid headers, form or query variables , and so on) and what happens when very large requests are sent to your server. You should create tests for all these situations. You should also be sure to do some ad-hoc testing, where once again Perl is your friend.

• Test all cases: This is probably the most obvious suggestion, but it s the easiest one to forget. Often, traditional application development teams are caught in the mindset of testing for positive scenarios. With server-side applications, and with Web applications in particular, it becomes very important (in some cases, more important) to test for negative cases. Are your authentication mechanisms working? Does your application handle invalid data correctly? On errors, is your application returning too much information to the user?

These are just some of the key work items that your team should keep in mind to ensure that the end result of your efforts is a secure application. Often just the education team members receive in creating a formal security plan justifies the cost of doing the work. The end result is a development team that is better able to find, review, and fix security issues before they hurt the application.