Wireless Application Protocol (WAP)

Wireless Application Protocol (WAP)

As you learned in Chapter 3, "Technologies," WAP specifications define a protocol stack similar to the Internet protocol stack. Each layer of the WAP protocol stack (Application, Session, Transaction, Security, Transport, and Network) represents an area where vulnerabilities can exist. The Wireless Application Environment (WAE), residing at the top of the WAP protocol stack, is the area of the WAP protocol stack on which we focus the bulk of our discussion here (see Table 5.1). Application issues are of interest for a variety of reasons. Although noteworthy security concerns are associated with all facets of WAP, the issues implicit in the lower layers of the protocol stack can be attended to similarly to wired Internet issues. Because those issues lower on the protocol stack can be mitigated, as WAP evolves, the Application layer becomes the most likely breeding ground for a new generation of attacks.

Faulty programming in the application environment and on the client can lead to serious problems in the wireless world, just as it can with any existing Web programming. In general, WAP developers should avoid translating existing Web applications to wireless ones by attempting modifications to the original code. Taking shortcuts can lead to vulnerable and poorly designed applications, at least where their usability is concerned.

Table 5.1. The WAP Protocol Stack

Functionality

Internet

WAP

Application

HTML

JavaScript

Wireless Application Environment (WAE)

WML, WMLScript

Session

HTTP

Wireless Session Protocol (WSP)

Transaction

HTTP

Wireless Transaction Protocol (WTP)

Security

TLS-SSL

Wireless Transport Layer Security (WTLS)

Transport

TCP

UDP

Wireless Datagram Protocol (WDP)

User Datagram Protocol (UDP)

Network

IP

Bearers: GSM, SMS, USSD, GPRS, CSD, CDPD, and the like

The WAE houses several services and functions to interact with its user agents: Wireless Markup Language (WML) and its partner script, WMLScript based on HTML and JavaScript, respectively. WMLScript enhances WML's standard browsing and presentation capabilities by providing client-side scripting functionality to WML. It supports advanced user interaction, validity checks for user input, and local messaging (error messages, alerts, and the like) and provides a mechanism to access the facilities resident on the client. It is designed for use on a WAP-enabled device, specifically on thin clients with low bandwidth communications capabilities.

WML was created to facilitate displaying Web pages on wireless devices with small display screens. If you recall the discussion of WAP in Chapter 3, you will remember that WML is analogous to a watered-down translation of an HTML page. In addition to small display screens, however, WML accounts for the fact that input to these devices is difficult and varied, memory is not available in excess, and CPU cycles are limited (for a discussion on how these limitations affect the implementation of cryptographic security solutions, see Chapter 6, "Cryptography").

WAP Browsers

More and more pages on the wireless Web are being written in WML to avoid having to translate to or from HTML. WML pages are not to be thought of as a substitute for standard Web sites. They provide only a limited subset of information and graphics to wireless device browsers. To view a WML page, a device must have a browser, an application used to interpret and render the WML code on a display. In the wired world, browsers are required to interpret HTML; some popular browsers are Netscape Navigator, Internet Explorer, and Opera. Several types of browsers, produced by various companies, can render WML. Each phone manufacturer decides the type of browser to install. Each PDA manufacturer decides either to install a given browser or to offer it as an add-on. As the mechanisms by which users update software on these devices become easier to use and more prevalent, the capability to upgrade these browsers becomes more commonplace.

To understand certain risks associated with viewing WML pages on a WML browser, we must first visit the risks associated with HTML browsers. In the case of HTML browsers, vendors often release security patches or updates to existing versions and, from time to time, full-blown new versions. Because each version of a browser is in use for some time, attackers take aim at holes inadvertently left by vendor programmers. By exploiting these holes, attackers gain sensitive information from users' systems. Sometimes the holes are so unfortunately placed and the attacks crafted in such a way that an attacker can take full control of a user's machine. Because HTML browsers can be customized when installed on a machine, it is possible to disable some of the functionality (that is, scripting or Java) that could enable exploits to come to fruition. By turning off scripting or Java, users can protect themselves from certain attacks, both known and unknown.

In a WML browser, these options are not as easily configurable by the end user yet. As time progresses, however, this will become status quo. Tailoring WML browsers to meet the security needs of business and personal users will become possible.

Staying consistent with one theme of this book, with all security features there are functionality drawbacks. In disabling features that could leave you open to an attack, functionality loss is suffered. In a corporate environment, a blanket policy requiring that all users disable Java and scripting could force functionality loss that is counter to business productivity. If staff who follow this policy cannot access critical applications or retrieve necessary information, this lack of ability is a problem. The appropriate course of action in determining which functionality to disable and which to leave vulnerable is to weigh all components of the issue, as discussed in Chapter 2, "Security Principles," and Chapter 11, "Analyze Mitigations and Protections." The answer to this question is found in examining the information to be protected, the risk if it is exploited, and numerous other factors.

If we could infallibly predict the occurrence of an attack, we could patent a Predicting Attacks formula and retire comfortably tomorrow. The factors that come into play in assessing the likelihood of an attack's causing damage are dynamic and often unpredictable. The uncertainty of these factors make calculating the likelihood of damage with any degree of certainty virtually impossible. Not enough variables can be isolated to solve an equation and come to a meaningful conclusion. Chapter 6 discusses in detail the process necessary to determine an appropriate course of action, but it cannot begin to calculate the likelihood of an attack in any specific percentage.

Obviously, using a browser for general home purposes is worth the risk of an attack. The information that can be gained, the applications that can be executed, and the convenience that is drawn from using an HTML browser to browse the Internet are usually viewed as significant enough to warrant risking an attack. If, however, you believe that the potential exists for anyone to attempt to compromise your computer through a browser hole, you may feel differently. By being aware of attacks, protecting your data, and keeping your browser up-to-date, you minimize this risk.

What is the risk in using WML browsers? It is much the same as in using HTML browsers. When attackers can exploit holes left by insecure code and architecture of a browser, wireless devices become open to attacks ranging from information leakage to complete control by a malicious party. Keeping the most current version of a browser is essential. Right now, the set of information available via these browsers is smaller than that which is available via HTML browsers, by its very nature. This is changing as quickly as the rest of technology.

Another significant risk in using WML, from a security perspective, is in the translation that occurs between HTML and WML. It is assumed that translation servers are trusted, but this assumption can lead to a false sense of security. To alleviate just one problem in a WAP system, clients could be required to accept only WML pages, avoiding the need to pass through a translation server in addition to an already risky WAP gateway.

Wireless Markup Language (WML)

Although WML is similar to HTML (closest to version 4.0) and XML, programming in it requires the use of different tags and structures. WML adopts its application model from HDML (Handheld Device Markup Language). It does require the XML-specified Document Type Definition (DTD) at the beginning of its code, including the official public identification of the Standard Generalized Markup Language (SGML) and the syntax definition for the document.

WML is, however, organized in a much different fashion. Converting a document from XML or HTML to WML is nontrivial. WML is ordered in decks of cards instead of groups of pages. When a user on a PC connected to the Internet types in a URL to request a Web page, the user's browser contacts the host server for the requested page and renders it via the browser on the user's PC. When a WAP-enabled cell phone user, for example, requests a Web page, the browser requests that page, termed a card, and returns not only the requested card but a set of cards, called a deck, or a group of cards associated with that single URL. The requested card is returned as the top card in the deck and is rendered by the cell phone browser for the user to view.

Because an entire PC-sized Web page cannot be rendered, it must be broken intelligently into smaller subparts (the cards) and delivered as a package (the deck) that can define user interactions and directions in displaying its information. The tag, <wml>...</wml> defines a deck and holds a group of cards together. The metaphor of decks and cards describes how the data is displayed when rendered in a browser, not how it is stored. A deck can be one file, beginning and ending with the <wml>...</wml> tags and containing <card>...</card> tags throughout to define the segmenting of the display on a wireless browser. The following is an example of a simple Hello World page in WML:

<?xml version="1.0"?> 
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" 
"http://www.wapforum.org/DTD/wml_1.1.xml"> 
<! Hello World in WML --> 
<wml> 
 <card id="Card1" title="WML example"> 
 <p>Hello World</p> 
 </card> 
</wml> 

Cards are named with an id in the <card>...</card> field so that they can be identified easily inside a deck. The reason cards are sent in decks and not individually is that the most costly parts of WAP data exchange are the communication round-trips. Anything that can be done to minimize the number of times a communication round-trip must be made decreases the cost of a system. Each card displays hyperlinks just as HTML pages do. The tricky part for programmers is to organize the decks as intuitively as possible. When calling up a page such as www.yahoo.com, for instance, the developer might guess that the user will want to view a subdirectory listing of a certain category, say, Local News, for the user's zip code. The developer would include with the initial deck some cards associated with top news stories in anticipation that a user will need to access those pages next. Alternatively, the developer might guess that the user will, instead, be searching for another lower-level directory listing of News so that she can choose among Associated Press news, Reuters news, or other newswire services, and the developer would send different cards in the initial deck. This deck might contain a card for the Associated Press and a card for each news agency for the user to select.

The two methods of sending cards to a deck estimated target hits down a vertical clickstream (that is, News, Local, Zip Code, Cards for each story) or a horizontal clickstream (that is, News, Cards for AP, Reuters, and so on) are useful in different situations. WML specifications make no design recommendations for organizing cards and decks. Making these judgments is up to developers. Adept understanding of user behavior and choices leads to cheaper applications. Developers who correctly anticipate the cards a user will likely need to access, based on links clicked from a previous card, will have more user-friendly and thus successful applications. This is not as much of a concern on the Internet as browsed by wired PCs. Except in the case of old billing models and slower speed connections, the time required to render a page on a wired PC is negligible and does not affect a Web site's organization in the same way.

When a user clicks a link, one of two actions can ensue. If developers and designers correctly anticipated the clickstream choice, the user clicks a link that refers to a card in the same deck. The initial card is moved to the rest of the deck, and the newly requested card is rendered at the top of the deck in the client's browser for the user to see. If developers or designers incorrectly guessed which cards the user will request next, the initial deck is discarded from memory, and a second deck is sent, with the requested card on top.

There are, of course, self-contained decks, those that perform a limited function and do not contain links to cards outside the deck. Browsing is much less taxing on a system and faster for users when this is the case.

Unlike HTML, WML is translated into binary code at the WAP gateway before being sent to the WAP device. To fit the narrow bandwidth typical in wireless communication, both WML and WMLScript code are compiled into bytecode on the server and then sent to the user agent. The bytecode is a binary representation of the text-based WML and WMLScript code. It is structured very similarly to binary executable files. The advantage of a bytecode file over a binary executable file is that it is machine-independent. It is compiled once and run on any machine capable of running a WMLScript interpreter.

WML browsers, WMLScript libraries, and a WMLScript interpreter are physically placed on the mobile client by its manufacturer. Because WMLScript compilation units are compiled into the WMLScript bytecode before they can be run on a WAP client, each client has a WMLScript interpreter that interprets the bytecode it receives.

The card/deck structure brings no direct security concerns to the table. What the structure does do, however, is introduce a new variable into the equation that inherently requires more time and effort on a developer's part. As with HTML, WML is a formatting language. Rendering the pages is up to the browser, not the language that describes how data will be displayed. In the browser is where you find security concerns (discussed later).

Protecting Deck Access Using the access Element

WML provides a basic method of protecting access to a deck. The access element allows a programmer to designate those entities that have access to a given deck. A browser attempting to access a card from a deck outside its current one enforces access control by this element. The browser must evaluate the permissions defined by the new deck to determine whether the existing deck can access its contents. The security concern brought about by this function is that it does not protect the data within the deck. The browser has access to the data while checking permissions. If the browser is trusted, this is not a problem. However, because the user has little control over the browser, a rogue browser could be created that would compromise the integrity of the data.

The method an access element uses to specify permissions is based on the domain and path of the originating request. The domain and path attributes are used to set these rules. See Singhal (2001) for examples of these. If neither a domain nor path is specified, the default access parameter is that only cards from the domain of the deck itself are allowed access to it (as long as the access element is invoked). If the access element is omitted, the deck is considered accessible from any source. Domains should be specified at the broadest level to which access is permitted. If you want to restrict a deck to be accessible by virginia.usa.com, maine.usa.com, and washington.dc.usa.com, you need to specify

<access domain="usa.com"/> 

Be aware that this also grants access to any originating domain that concludes with usa.com. If you want to restrict the deck further to include vienna.virginia.usa.com and oakton.virginia.usa.com but to exclude portland.maine.usa.com, you need to specify

<access domain="virginia.usa.com"/> 

This excludes anytown.anyotherstate.usa.com because the allowable domains must be an exact match.

Protecting Deck Access Using the path Element

The second way of limiting access is by specifying a path. The path attribute designates access to decks in given paths on the application server. The path is derived from the prefix of the requesting or originating card. The beginning of this path must be an exact match as well. If you have, for example, a WML document residing at http://usa.com/states/list.wml and the following specification is set, any document that falls below the /states tree and is also below the usa.com domain can access the deck:

<access path="/states"/> 
Coding with Due Diligence

Recall the Chapter 2 discussion of security concepts. Access control is not security.3 Much more is involved in protecting data, resources, systems, and applications. Responsible coding is a large part of developing secure applications. This book does not endeavor to discuss every element of WML or J2ME (or any other wireless programming language, for that matter) with respect to security considerations. Instead, we recommend that coders know the languages inside out, be aware of the common pitfalls, and understand appropriate methods for building secure applications. Although we explain the architectural considerations necessary for making decisions about designing secure wireless applications, due diligence dictates that coding be taken seriously. The importance of investing in coders with appropriate security background cannot be stressed enough. We recommend the following resources to bolster the actual coding of secure wireless applications.

Wireless Application Protocol Specifications

The specifications for WML are available at http://www.wapforum.org/what/technical.htm. Although they are a good resource for learning the building blocks necessary to code in WML, they do not provide solid security architectural design recommendations. A little knowledge can be dangerous. An understanding of the specifications outlined by the WAP forum is essential but not nearly enough to make you adept at writing secure code.

Device-Specific Books

After you decide that you need to code to a certain device, you should certainly learn more about the security design recommendations for that device. Books we find helpful include

         Palm Programming: The Developer's Guide by Neil Rhodes and Julie McKeehan

         GPRS and 3G Wireless Applications: The Ultimate Guide to Maximizing Mobile Internet Technologies by Christoffer Andersson

         The Wireless Application Protocol: Writing Applications for the Mobile Internet by Sandeep Singhal et al.

Other helpful books are appearing on shelves daily. At the risk of repeating a lesson surely taught in programming classes, understanding the relationship between the language and the device on which it will be used is crucial. (Although this is suggested here in the context of WML programming, examining these resources is important, no matter which language is chosen for development.)

General Software Security Books

After you master the mechanics of coding in a new environment, you must incorporate certain security design paradigms necessary to building applications in general, whether or not they are for the wireless world. When reading a book on general software, you must bear in mind the limitations the wireless realm brings to the table. As recommended earlier, Building Secure Software by John Viega and Gary McGraw is a valuable resource in this domain. It focuses on the security aspect critical to many applications. (Regarding device-specific books, note that this is also applicable to J2ME-developed applications or applications in any other wireless language.)

WML by itself affords limited function. It describes formatting, contains text, provides links for navigation, and contains commands that can be used to run scripts. It does not allow programmers to perform all the functionality necessary to develop robust applications. For this reason, WML Script was introduced.

WMLScript

WMLScript is based on ECMAScript and JavaScript. According to its specifications, WMLScript uses similar syntax and constructs and provides semantically equivalent functions. The theory behind WMLScript is different from that supporting JavaScript. It is designed for capability-limited devices.

WMLScript gives WML added functionality just as JavaScript adds to Java. With WMLScript, WML decks can perform processing they would otherwise rely on a server to perform. WMLScript enhances WML by providing browsing and presentation functionality that betters WML pages from a usability standpoint. The following is a list of functions that WMLScript adds to WML, according to its specifications:

         Checks the validity of user input

         Provides access to the device's facilities (for example, on a phone, allows the programmer to make phone calls, send messages, add phone numbers to the address book, access the SIM card, and so on)

         Generates messages and dialogs locally, thus reducing the need for expensive round-trips to show alerts, error messages, confirmations, and the like

         Allows extensions to the device software and the capability to configure a device after it has been deployed

         Provides more advanced user interface functionality

         Reduces the amount of bandwidth needed to send data between the server and the client

WMLScript libraries add significant functionality and are present in devices designed to interpret and render WML and WMLScript. The default libraries, however, can and should be expanded on to include custom libraries that enable applications to access the features of a device that make it unique. The feature that distinguishes a Handspring Visor from a Palm Vx cannot be easily invoked with generic libraries. Coders with a certain amount of prowess can dispatch specific libraries to make the most of their devices' special properties. If you are developing applications for cell phones, perhaps tailored WMLScript libraries can define specifics related to call control, synchronization with a PDA, or access to various storage areas in the device.

WMLScript is similar in syntax to C++ or Java. It is case-sensitive, and statements are terminated with a semicolon. As in C++, a double slash indicates a line comment, and a statement beginning with /* and ending with */ denotes a block comment. WMLScript is a procedural language that is extendable by adding the customized libraries just mentioned. It is not object-oriented, nor does it have an object model. Instead of ECMAScript's 64-bit floating-point math, WMLScript features 32-bit integer math with optional floating-point support. Unlike WML, it does not support global variables and does not have appropriate error handling. The error-handling mechanism is based only on the (invalid) error value. The invalid data type is distinct from strings, integers, and so on, and carries with it its own rules. In most cases, the presence of invalid in an expression causes the result of an expression to be invalid.

WMLScript supports standard libraries of WMLScript procedures installed on the clients themselves. It does not support certain more advanced features of JavaScript that require more computational or bandwidth capabilities. WMLScript can call remote scripts via URLs but cannot invoke libraries physically located on the client besides those in its own libraries. WMLScript compilation units, resources, and functions are accessed by using URLs because they are not embedded in WML code. A user agent can make a call to an external WMLScript function by providing the compilation unit's URL and the function name and parameters as the fragment anchor. The requested URL must be escaped according to the URL escaping rules because no compile-time automatic escaping, URL syntax, or URL validity checking is performed.

Telephony Functions

One of WMLScript's main additions to WML is that it allows applications to access client functions. Of particular interest are those mechanisms designed to interact with the client's telephony-related functions. These mechanisms, called Wireless Telephony Applications (WTA), include features that need to be protected from unwanted use or access in security considerations in applications and networks. The WTA functions are

         Accepts or initiates a call

         Sends or receives text messages

         Adds, searches, or removes phonebook entries

         Examines call logs

         Sends Dual Tone Multi-Frequency (DTMF) tones during an active call

         Presses keys on a keypad during a call

WMLScript invokes the WTA Interface (WTAI) to manipulate telephony functions of the phone. WTAI functions are included in WMLScript libraries and are called as WMLScript functions. These types of functions have parallels in the wired Internet world but invite different exploits in the wireless world. A whole host of new attacks can be designed to use these seemingly benign functions in a malicious way. WTAI functions that access phonebook entries provide WMLScript access to storage areas in the phone. Whether this simple access to an indexed array such as the phonebook can be extrapolated into misuse has to be investigated. Certain exploits can be constructed by manipulations that are not intended but also not prevented.

For a good description of the literals, variables, type conversions, operators, identifiers, statements, and functions used in WMLScript, see Chapter 9, "Scripting and Using WMLScript and WTAI," of The Wireless Application Protocol: Writing Applications for the Mobile Internet by Sandeep Singhal et al. These are worth investigating but do not differ enough from other languages to warrant significant concern on our part for their wireless implications.

Risks and Exploitation

Current WMLScript applications are predominantly benign, accessing WTAI functions for legitimate purposes such as placing a call from a link on a WML page, directing incoming calls to voice mail upon a user's request, or forwarding an incoming call to a different phone number. These benign uses, however, come dangerously close to malicious activity.

In the wired Internet world, different browsers behave differently. Wireless phone browsers are not an exception. Discrepancies run rampant among browsers, phone manufacturers, and applications alike. The major WAP-enabled phone manufacturers such as Nokia, Ericsson, and Motorola provide SDKs that specify differences in countless implementations. As in the wired Internet arena, time to market for WAP applications is decreasing rapidly. While developers race to produce new applications, the myriad inconsistencies require layers of minute coding differences that can be easily dismissed, leading to serious security flaws.

This complicates the problem originally facing developers, that there are many functions on which malicious users can attempt to get their hands. Placing unauthorized long-distance calls and broadcasting or erasing phonebook entries are only two of the problems that must be prevented with safe coding practices.

For example, the intended implementation of the WTAI function WTAVoiceCall. setup that makes a call is to display the phone number before the call is made. If the WAP browser being used does not prompt the user before placing the call, the call is automatically activated. In Japan, a prank was played on phone users who pressed a number in response to a voice mail message that automatically dialed the Japanese police emergency number without the callers' knowledge. Japan uses imode technology, which is different from WAP but represents an initial exploitation of a native capability.

The specifics of the browsers for which your team develops must be investigated. If a browser does not protect against certain potentially malicious activities, prevention mechanisms must be built in to the applications.

In the security model, some risks will be avoided. Calling functions that are not external, passing illegal parameters, and accessing a WMLScript called from an unauthorized domain and path will be prohibited. DNS spoofing, however, can circumvent the last of those three, possibly sending unwanted information to an unknown location. A smart WAP programmer recognizes that to be completely safe, certain additional safeguards should be taken in WMLScript usage not only in the use of WTAI functions but also with respect to all areas of the client so that even trusted servers and gateways cannot be the scene of an unwelcome attack.

The restrictions on WMLScript span beyond the realm of WTAI functions. WMLScript has few limitations and access control parameters. It is up to developers, service providers, and gateway hosts to control which parts of the client are protected and under what conditions they can be accessed. WMLScript libraries have limited functions and have methods for controlling their use. The problem is that the controls are not necesssitated; they are merely suggested.

Securing information on a phone is possible, but loose coding practices open doors to many forms of attacks. These range from minor infractions, such as dialing fake phone numbers to increase long distance bills, to major problems, such as deletion of confidential information on the phone (the user's unique ID, for example) or, in the case of smart card enabled phones, stealing credit card information or other sensitive data.

 



Wireless Security and Privacy(c) Best Practices and Design Techniques
Wireless Security and Privacy: Best Practices and Design Techniques
ISBN: 0201760347
EAN: 2147483647
Year: 2002
Pages: 73

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net