WML for Secure Applications
When creating WML decks, you have a few techniques available to ensure that sensitive information does not leave the secure communication channel between the user and your application. This section will cover the mechanics of protecting your decks from attacking applications using the access element and the sendreferer attribute. I will also show you how to make sure your application doesn't leave trace data behind.
Restricting Access
WML allows you to tell the browser to keep other applications from linking into decks within your application. That is, WML provides you the access element in which you specify where the linking deck must live in order to reference your deck successfully. Its syntax is simple, as you can see from the DTD snippet:
<!ELEMENT access EMPTY>
<!ATTLIST access
domain CDATA #IMPLIED
path CDATA #IMPLIED
%coreattrs;
>
This allows you to control the way in which decks and users enter your application. For example, on a shopping site, you would want the checkout to be accessible only from your product pages; you would want to keep another application from throwing a user there directly.
You can add the access element to the <head> tag of any deck. The absence of the <access> tag allows any deck to reference that deck. When configuring the element, you should specify the path and domain attributes explained in Table 12.1.
| Attribute | Type | Behavior |
|---|---|---|
| domain | CDATA | Web domain of permitted decks, for example, http://wapform.org |
| path | CDATA | Path under the Web server of permitted decks, for example, /specs/ |
The domain attribute controls the set of Web servers that can link into your application. The value permits any deck originating from that domain, whether a specific machine (http://www.wapforum.org) or just an entity (http://wapforum.org). This mechanism is called suffix matching. The default value for this attribute is the domain of the Web server supplying the deck, permitting all decks in the domain access to your deck while restricting all out-of-domain decks.
The path attribute restricts access within a domain in order to thwart cross-application linking. It permits any decks in a more specific path access. An application at path /apps/foo would be permitted access if the path attribute had value /apps. The default value for the path attribute is /, giving all decks within the domain access to your deck.
You need to supply the access element on each deck that should not be linked from another site. The deck in Listing 12.7 shows an example of its use.
Listing 12.7 Using Access Control on a Deck
The deck in Listing 12.7 contains a simple access element that restricts access to its home directory, cryptically named 946212. The deck then adds a single card that links back to the same deck using a different path through the Web server, 946212s. While the mechanics for this are not always well implemented, as you can see in Figure 12.11, the browser will deny access to the second deck.
The deck in Listing 12.7 relies on the browser to enforce access control. When creating an application, you may wish to be more proactive and control this access at the server side. To permit this, WML has added the sendreferer attribute to the <go> tag.
The sendreferer attribute is quite simple to use—it simply takes a %boolean value. true and false are legal assignments. This attribute instructs the browser to send along the HTTP variable describing the deck that makes a request. This variable, HTTP_REFERER, simply contains the URL of the deck making the request. You can then decide, in your application logic, whether to permit the linking deck access.
Figure 12.11. Denying access to decks that do not deserve it.
Unfortunately, the sendreferer attribute defaults to the false value, suppressing this valuable information. You should get into the habit of specifying this attribute as true each time you create a go element, even if you don't need access control immediately.
Cleaning Up
There is one last thing that you must take care of when you create an application that handles sensitive information: you must clean out your variables. This is critically important when you create decks that retrieve passwords, social security numbers, and so on. You cannot leave the data that the user enters into the browser in memory since the next deck may be able to access it and deliver it to another application against the user's wishes.
As you've probably noticed, most of the decks I create clear out the variables that I use before I use them. I do this using the onenterforward event, refresh, and setvar elements. You should make sure that each time you retrieve data from the user and leave the deck, you also clear out the in-memory data. Listing 12.8 demonstrates the simple mechanism for this using the manual authentication deck from Listing 12.1.
Listing 12.8 Clearing Out Sensitive Information
The deck in Listing 12.8 simply adds the same <setvar> tags to the exit point that I used to clear out the data when entering. The <go> tag preserves the order of its children, so you must place these variable resets after the <postfield> tags. This is a good habit to get into, not only for sensitive data, but for all data your deck uses; it adds very little size to the compiled deck—about 15 bytes in this case.