Writing HDML that minimizes security risks

There are a number of HDML options that control security risks from malicious services. The following table summarizes them:

Element	Option	Description
Deck	`PUBLIC`	Enables access control. Setting it to `FALSE` limits the URLs that can link to cards in the deck, according to the `ACCESSDOMAIN` and `ACCESSPATH` option settings. Setting it to `TRUE` allows any URL to link to cards in the deck. It is set to `FALSE` by default.
	`ACCESSDOMAIN`	Specifies the domain of URLs that can request cards in the deck when access control is enabled. The default value is the current deck's domain.
	`ACCESSPATH`	Specifies the base path of URLs that can request cards in the deck when access control is enabled. The default value is `/` (the root of the current deck's path).
Task	`FRIEND`	Specifies whether a nested activity can clear the current activity's variables and whether it can override the current activity's `NEXT` and `CANCEL` options.
Task	`SENDREFERER`	Specifies whether the UP.Browser should provide the URL of the current deck when requesting the URL specified by the `DEST` or `NEXT` options. If you set it to `TRUE`, the phone specifies the deck's URL in the "Referer" header of the request.

For detailed instructions on using the PUBLIC, ACCESSDOMAIN, and ACCESSPATH options, see HDML access control.

If you don't specify the options listed in the table above, the phone uses default settings, which provide the highest degree of security. For example, PUBLIC defaults to FALSE (enabling access control) and ACCESSDOMAIN and ACCESSPATH default to the domain and root path of the current deck--which means that only URLs with the same domain as the current deck can request cards in the deck.

In general, the default settings for the HDML options described in the table above provide the most security. However, there are some specific areas where you should be cautious. These are described in the following sections.

Using the MARKABLE option

Setting the MARKABLE deck option to TRUE allows the user to bookmark any of the cards in the deck, by default. It also implicitly sets the PUBLIC option to TRUE, which allows any URL to directly request any card in the deck. If the deck contains cards that conduct sensitive tasks, this is a security risk.

Using NEXT and CANCEL task options

The NEXT and CANCEL task options are described in Specifying navigation between activities. They allow a GOSUB task to specify cards to display when the nested activity specified by the task returns. NEXT specifies the card to display when the nested activity returns using the RETURN task; CANCEL specifies the card to display when the nested activity returns using the CANCEL task. The phone uses an implicit GO task to display the cards specified by a task's NEXT and CANCEL options. This means these cards are part of the same activity as the card that specifies the task--they have access to the activity's variables.

By itself, including the cards specified by the NEXT and CANCEL options in the same activity does not pose much of a risk: you specify URLs that you know are not malicious for these options. However, if you set the FRIEND option of the GOSUB task to TRUE, the nested activity can specify a DEST option in its RETURN or CANCEL task--this overrides the NEXT and CANCEL options that you specified. If the nested activity specifies one of its own cards as the destination, that card has access to all of your activity's variables. If those variables contain sensitive information, it is a security risk.

HDML provides the FRIEND task option to contain this risk. The FRIEND option specifies whether a nested activity can override the current activity's NEXT and CANCEL options. By default the FRIEND option is FALSE, which means that the nested activity can't override the NEXT and CANCEL options; if it specifies a DEST option in its RETURN or CANCEL tasks, the phone ignores it. If the nested activity specifies the CLEAR option to clear the calling activity's variables, the phone also ignores it.

Checking the HTTP request Referer heading

If your service provides URLs that perform sensitive operations, it should check the HTTP Referer header (the HTTP_REFERER environment variable set by the Web server) to make sure that the requests it handles originate from friendly domains. Note that the phone does not set the Referer header unless the deck making the requests has set the SENDREFERER task option to TRUE.