Security Issues and Principles
Just as the increased internetworking among organizations has driven the need for globalization and localization discussed in the previous chapter, the increased internetworking among computer systems has increased the need to take security seriously. One need look only at the Code Red and Nimbda attacks of recent years to understand the havoc wreaked by malicious people and the software they write. And for every public incident, a myriad of internal security breaches are discovered.
 | And just as Microsoft has rededicated itself to security by launching its Trustworthy Computing initiative,[1] your organization should also design and implement its applications using secure coding practices. This is the case because even applications written with the Compact Framework are vulnerable to exploitation due both to their portability and to their need to connect with back-end systems to exchange data. To give just one example, Gartner Group estimated that a quarter of a million handheld devices would be left behind or lost at U.S. airports in 2001.
|
However, before discussing the specifics of securing Compact Framework applications, a brief review of some core security principals or maxims is in order either to refresh your memory or to orient your mind to issues you'll need to face when developing Compact Framework or, indeed, any other kind of software.
Apply defense in depth. This principle asserts the often-repeated phrase that security is only as strong as its weakest link. Because most software is designed in layers and applications incorporate encryption, firewalls, Web servers, and more, architects and developers need to take all of these layers into consideration.
Reduce the attack surface. This principle is a restatement of the obvious: It's easier to hit a barn than it is a tool shed. By disabling features of software that can be attacked, the size of target area for malicious users is reduced.
Don't trust user input. This is perhaps the principle that developers can be most proactive about. As discussed in the sidebar "Beware of SQL Injection Attacks" in Chapter 7, developers must always protect their applications against malicious data introduced through normal user input methods. This can entail both traditional data entry through a forms-based interface and automated data entry through XML Web Services and XML files.
Use least privilege. This principle asserts that by restricting the permissions of the identity under which the code is running, you can limit the amount of damage malicious users can do. Although single-user operating systems such as Windows CE, upon which the Compact Framework runs, do not typically support various permission levels, this principle's application in server software such as ASP.NET can go far toward protecting an application.
Obscurity is not security. This principle has two primary applications. The first is that simply because an application resource (such as a URL when using SQLCE replication) is not well known or published publicly, this does not mean it is not vulnerable to attack. In the case of Web servers, it has been well documented that even anonymously deployed servers record attempts by hackers to break into the systems within hours. The second is that home-grown attempts at security, for example devising custom encryption algorithms, will not typically be as secure as industry-standard techniques, for example, symmetric encryption algorithms like Triple Data Encryption Standard (Triple-DES).[2]
[2] Triple-DES is a symmetric encryption algorithm based on the original DES algorithm developed in 1974 and adopted as a standard in 1977. It uses three 64-bit keys (hence the name), rather than one and, therefore, encrypts the data three times.
Fail securely. This principle is a reminder that even if an application is designed with the other principles in mind, an application that gives away its own secrets through default error messages and stack dumps renders adherence to the other principles moot. This is true even in simple cases, for example, an application that simply displays "Invalid Credentials" rather than "Invalid Password," which allows hackers to note when they've discovered a valid user account.
Each of these principles could be discussed in much greater depth. For more information on this topic, we recommend Howard and LeBlanc's Writing Secure Code referenced in the "Related Reading" section.
As mentioned in the first principle, security must be applied in depth in order to protect the weakest link. To that end the remainder of this section discusses securing the three principle layers in a Compact Framework application: the device, the application, and the communications layers.
