The Two Environments of Wireless Programs

The emphasis of many wireless development efforts today is the Web. However, most mobile devices support both a local (or desktop) environment and a Web environment. It’s easy to come up with a number of reasons for the emphasis on Web development. Many developers consider the Windows CE toolkits one of the harder IDEs to use for development. In addition, Web-based applications commonly work with more than one platform. A single Web-based application could meet the needs of a cellular telephone, a Pocket PC, and a Palm. In fact, given enough time, a developer could create a single application that would meet all of these wireless needs and the needs of desktop users too. In short, you can find many reasons to use Web-based applications to the exclusion of everything else.

However, the desktop environment has a certain appeal as well. First, the user doesn’t require a connection to anything to use the application. Second, an application designed for local use can rely on the special features provided by the device. Finally, the local environment is more secure simply because you eliminate the problems of using a wireless connection. In short, both environments have something to offer.

Note

Application testing is complex. Testing desktop and Web-based applications that need to work together is more complex. Adding wireless to the equation makes testing even more complex—some say nearly impossible. Complexity breeds security problems because complex issues often require a level of analysis that few developers can provide. One InfoWorld column by Wayne Rash (http://www.infoworld.com/article/03/05/16/20secadvise_1.html) reminded me that even the industry pundits have a hard time figuring out what to test, much less how to test it. In this case, the columnist asks readers not only to help him discover which security devices to test, but to offer input on how to test them.

When you write applications to the lowest common denominator, you usually give something up. This book won’t go into all of the flexibility and performance issues that Web-based applications can incur. However, the following sections do discuss security issues you need to consider. Each environment incurs security penalties that you need to consider as part of your development effort. Combine these limitations with the lack of security functionality in the .NET Compact Framework and you’ll see the need to discover creative solutions to security problems.

Overcoming Direct Execution Problems

This section discusses the PDA. Unless technology changes significantly, cellular telephones will remain connected to the Internet as their only significant means of application communication (that is, they can only use the Web environment). In addition, the Smart Device Application template currently provided with Visual Studio .NET 2003 doesn’t include support for anything other than the Pocket PC (you can’t even work with the Palm).

For the most part, wireless applications don’t exist in a secure environment, even when you use the Smart Device Application project to build a Windows application. However, the desktop environment is more secure than the Web environment simply because you have more control over application execution and data handling. Standalone applications are the most secure because you don’t have to deal with the vagaries of transmitting information over a wireless connection.

Of course, the assumption is that you’ll always use a wireless connection for your application. However, you have to consider whether this is a valid assumption. You can synchronize to a host machine by placing the PDA in the cradle (or using some other hard-wired connection). When you don’t need a live connection, using the synchronization feature works well. A service on the host machine can detect data changes and take the appropriate action.

Live connections don’t necessarily mean a nonsecure environment. You can add a network card to your PDA that allows a direct connection. (I currently have a Kingston model CIO10T, but there are likely other products on the market.) Unfortunately, this means you have a physical connection to the network again, and many people like their PDA because it frees them from the limitations of a physical connection. Even so, requiring a physical network connection to transfer sensitive data can reduce your risk substantially. You can ensure that the user uses a network connection by checking for the network adapter in your code and using that connection with members of the System.Net.Sockets namespace. (See Listing 8.1 for one example of how to use sockets within an application—the associated explanation details some of the security issues you need to consider for an application that relies on a socket connection.) Use a TcpClient object on the PDA and a TcpListener object on the server to create a direct connection.

Another alternative is to use the Infrared Data Association (IrDA) connection. You implement this solution by creating an IrDAClient object on the PDA and an IrDAListener object on the host. The advantage of this method is that you don’t have to worry about a wire. In addition, IrDA doesn’t transmit in every direction as wireless does, so it’s more secure than wireless. Unfortunately, although it’s portable, you need a line-of-sight connection to the host because IrDA uses light transmission to make the connection. You can find a discussion about using IrDA for communication purposes at http://dotnet247.com/247reference/msgs/27/137277.aspx.

Avoiding Browser-Based Application Issues

At some point, you’ll have to consider using a Web-based application to meet specific needs. Web-based applications normally run with some type of wireless connection when you use a cellular telephone or a Palm. A Pocket PC can theoretically make a connection to the Internet through a host using a standard network connection (see the “Overcoming Direct Execution Problems” section for details on this solution). The point is that you’ll access the application using a browser.

While you can use Secure Sockets Layer (SSL) to secure the communication when the mobile device browser supports it, generally, mobile browsers will access the application using only the functionality provided by the wireless connection. The reason is simple—an application that runs slowly on a desktop using SSL will be nearly unusable with a mobile device such as a cellular telephone. The speed of the device becomes a hindrance in securing the application using this simple technique.

More about Web-Based Security

One of the more interesting places to learn about Web-based security threats is Internet Security Systems (ISS) (https://gtoc.iss.net/issEn/delivery/gtoc/index.jsp). The main page tells you about the current security state of the Internet, which is valuable to a developer planning an application deployment. ISS does sell security services and it provides articles on the latest security threats. You can view this information at http://xforce.iss.net/. Most developers will benefit most from the Internet Risk Impact Summary—a report you can download at https://gtoc.iss.net/documents/summaryreport.pdf. For example, this report will tell you that 33 percent of all security incidents happen on Friday and Saturday. You’ll also discover that many attackers prefer ports 135, 137, 138, 139, and 445. The selection of these ports is interesting. For example, Microsoft Exchange clients use port 135 to communicate with the server. You can see Microsoft Knowledge Base article 176466 (http://support.microsoft.com/default.aspx?scid=kb;[LN];176466) for details on Exchange port usage.

Fortunately, it’s relatively easy to detect the kind of device that’s requesting services from a Web application. The ASP.NET Mobile Web Application template provides built-in functionality for determining the device type. The initial goal of this support is to help you build applications that scale to specific devices—it helps you size the screen to meet the needs of the device. You can also use this information to consider the effect of the device on security. For example, a cellular telephone is going to be a lot less secure than a desktop machine connecting to the same application. Consequently, you can leave specific features out of the cellular telephone version of the application.

One of the easiest ways to leave information out of a less secure mobile version of an application is to use filtering. All of the controls and forms supported by ASP.NET include an (AppliedDeviceFilters) property. Click the ellipses button for this property and you’ll see an Applied Device Filters dialog box similar to the one shown in Figure 13.6.

Figure 13.6: Use filters to define custom setups based on the caller type.

Notice that Figure 13.6 includes a number of device types. Visual Studio .NET 2003 includes a number of default filters that handle most situations. You can also click Edit to create a custom filter or adjust the settings of an existing filter. The point is that you have a way to detect the client and modify the information you present. This capability lets you secure the application based on the caller’s ability to maintain a secure connection.

What isn’t apparent in Figure 13.6 is that you’re adding HTML tags to the application. It also isn’t apparent that you can modify these tags to perform specific tasks. For example, you can set the filter for a specific device to make the associated control invisible. To set these properties, click the ellipses next to the (PropertyOverrides) property. You’ll see a Property Overrides dialog box similar to the one shown in Figure 13.7.

Figure 13.7: Use property overrides to change the page appearance and functionality.

The Applied Device Filter list only contains those devices that you added to the list in Figure 13.6. In this case, the code changes the lblGreeting.Text property to read Pocket IE Client. However, the client won’t actually see the greeting because the Visible property is false. You can still interact with the information in code, so it’s essential to set the values as needed. Listing 13.2 shows how these changes affect the tags for the ASPX page. (You can find this example in the \Chapter 13\C#\ClientCapabilities or \Chapter 13\VB\ClientCapabilities folder of the source code located on the Sybex Web site.)

Listing 13.2 Tag Changes Based on Filter Settings

<mobile:Label  runat="server">    <DeviceSpecific>       <Choice Filter="isPocketIE"               Argument="Visible=False"               Visible="False"               Text="Pocket IE Client">       </Choice>       <Choice Filter="isMyPalm"               Argument="Visible=False"               Visible="False"               Text="Palm Client">       </Choice>       <Choice Filter="isHTML32"               Argument="Visible=True"               Text="HTML32 Client">       </Choice>    </DeviceSpecific> Hello</mobile:Label>

The <DeviceSpecific> tag sets off a list of device choices. Notice that each of the <Choice> tags contains settings for a particular device, so you have good control over the property settings. The server doesn’t tell the client about controls that lack information or are invisible. As far as the client is concerned, the lblGreeting label doesn’t exist if you set its Visible property to False. Data hiding is an essential part of maintaining security when you have to work with wireless devices. Only tell the client what it needs to know in order to perform specific functions.

Fortunately, you can also manipulate the controls from within your code. When working with a database application, you might choose to send a subset of the information to a wireless client. You can’t perform this task using the <Choice> tag, so you have to perform the filtering in code. Listing 13.3 shows an example of how you can access information about the current client using the DeviceSpecific property.

Listing 13.3 Using the DeviceSpecific Property

private void btnTest_Click(object sender, System.EventArgs e) {    // Display the device specific information.    txtOutput.Text = "The device specific data is:" +       "\r\nCount: " +       lblGreeting.DeviceSpecific.Choices.Count.ToString() +       "\r\nArgument: " +       lblGreeting.DeviceSpecific.SelectedChoice.Argument +       "\r\nFilter: " +       lblGreeting.DeviceSpecific.SelectedChoice.Filter; }

The DeviceSpecific property lets you access what amounts to an undocumented object, System.Web.UI.MobileControls.DeviceSpecific. (You can view the current documentation for this object at http://msdn.microsoft.com/library/en-us/mwsdk/html/mwlrfDeviceSpecificClass.asp.) Some of the features of this object appear in the TemplateControl class. The two most important features of this object are the Choices collection and the SelectedChoice property. The Choices collection tells you about the device choices currently enabled for the page, while the SelectedChoice property contains a DeviceSpecificChoice object that contains the current device properties.

Use the Choices collection to add new DeviceSpecificChoice objects to the page and to check on the current choices. This collection works the same as any other you’ve used with Visual Studio .NET. It includes an enumerator you can use to list the choices, an Add() method, and a Remove() method.

You might wonder what would keep a cracker from attempting to change the device settings to obtain additional rights to the page. First, your CLR compiles your application and loads it into memory, so the cracker would have to perform something akin to a buffer overload exploit. Second, the various objects include a GetHashCode() method. This method enables you to use a technique similar to the one shown in Listing 13.1 to verify the integrity of your code at any point.