Common security risks for HDML services

The most common type of security risk is presented by a phone subscriber voluntarily requesting a "malicious" service that is masquerading as a legitimate service. Such a malicious service might attempt to use the phone subscriber's access to your HDML service illicitly. There are several ways it might attempt to do this:

• By directly accessing a card in your service that conducts sensitive operations, such as banking transactions or stock trades

• By gaining access to variables in your service that provide confidential information, such as messages and financial information

• By clearing variables used by your service

Figure 6-1 shows a simple example of a security risk. A banking service allows the user to transfer funds. The user presses ACCEPT in a card that describes the proposed transaction; the card's ACCEPT action invokes the URL of a script that conducts the fund transfer.

The malicious service, depicted on the left, poses as a weather service. When the user presses OK to get the weather, the service requests the fund transfer URL from the banking service, using slightly different arguments. The user thinks that he or she is requesting today's weather report, but is actually transferring funds to the owner of the malicious service.

FIGURE  6-1.     Potential security risk

To avoid this risk, the banking service should make several changes:

• The card that requests the funds transfer should set the SENDREFERER task option to TRUE.

• The script that actually transfers funds (transfer.cgi) should check the URL specified by the REFERER header of the HTTP request to ensure that the request is coming from one of the banking service's decks.

• The service should use HTTPS and require basic authentication, just as it would if the transaction were being conducted with a conventional Web browser. Relying on the phone's identity alone does not provide sufficient security.