WAP and Mobile HTML Basics
Wireless
Application Protocol provides a method to access the Internet from
mobile devices. WAP architecture includes a few items, such as a WAP
browser on the mobile device, the destination application/HTTP web
server, and a WAP gateway in between the mobile device and the
application/HTTP web server. A WAP gateway is an entity that acts much
like a proxy server between a mobile device and the HTTP server. Its job
is to translate content from web applications in a form readable by
mobile devices, such as with the use of WML.
WAP has two major
versions: WAP 1.0 and WAP 2.0. It should be noted the WAP gateways are
required in WAP 1.0 but are an optional component in WAP 2.0. Figure 1 shows a WAP architecture.
In the early days of WAP, which
used WAP 1.0, Wireless Markup Language (WML) was solely supported. WML
was based on HTML, with limited to no support for cookies. WAP websites
heavily relied on WML to display content to users,
but quickly ran out of all the bells and whistles that users/developers
desired. About four years later, WAP 2.0 was established. WAP 2.0
supported more items that make the web experience similar to the PC,
such as xHTML, CSS, TLS, and wider support for cookies. Furthermore, WAP
2.0 no longer required a WAP gateway, which alleviated some security
concerns with WAP 1.0 (discussed in the WAP 1.0 section). As the
industry continued to evolve, so did mobile devices. Nowadays, WAP 2.0
and Mobile HTML sites dominate mobile web applications. Mobile HTML
sites are slimmed-down versions of tradition web applications, but
viewable on devices with limited view screen and storage capacities
(usually with a smartphone or PDA).
Authentication on WAP/Mobile HTML Sites
One of the many problems that
WAP and Mobile HTML developers have with mobile devices is the keyboard.
PDA-style phones come with a mini-keyboard that looks similar to
traditional keyboards, containing letters A–Z and support for every
number (0–9) and many special characters by using a SHIFT-style key (see
Figure 2).
On the other hand, non-PDA
phones have the traditional 0–9 keys only, with letters above numbers
2–9 and special character support under number 1 or 0 (see Figure 3).
Although the use of PDA-style
mobile phones is increasing every day, non-PDA mobile devices are the
most popular, which have the traditional 0–9 keys only. The limitation
of the 0–9 keys creates a significant challenge to WAP and Mobile HTML
developers in terms of user experience and authentication. For example,
banking and e-commerce organizations want to make authentication to
their sites as easy and secure as possible, thus making the adoption
rate high. Traditionally, strong passwords are often required for
banking and e-commerce sites, often requiring numbers, letters, and
a special character. Although these standards are great when a
traditional keyboard is available, they become very difficult when only
the 0–9 keys are available on traditional handsets. For example, using
the keyboard in Figure 9-2, the relatively simply password of isec444 would only require selecting the letters i-s-e-c,
selecting the SHIFT key, and then selecting the number 4 three times,
requiring a total of eight key presses. On the flip side, the same
password used with the keys shown in Figure 3 would require selecting the number 4 key four times (to get to i), the number 7 key five times (to get to s), the number 3 key three times (to get to e), the number 2 key four times (to get to c),
and then the number 4 key three times, for a total of 19 keypresses.
The latter option requires more than double the effort to enter a simple
password and virtually kills the user sign-on experience.
In order to create a better
and easier experience, mobile WAP/Mobile HTML sites have introduced the
use of a mobile PIN, which replaces the password; however, this also
lowers the security of the authentication process. For example, many
WAP/Mobile HTML sites allow a phone to be registered to an account.
After a phone is registered via a web application, the mobile phone
number can be used instead of a username, and a mobile PIN can be used
instead of a password. Unlike traditional passwords, the mobile PIN can
only be numbers and is usually four to eight values in length (with at
least one major bank limiting PINs to only four numeric values only).
The use of a numeric-only value for the PIN increases the user
experience by significantly reducing the amount of keypresses to use the
mobile device (the same idea holds for the username, by the use of a
numeric phone number instead of an alphanumeric username). In either
case, when the username is replaced with a phone number and the password
is replaced with a PIN, the user experience is improved, but security
is reduced. In this use case, a site that usually takes a unique
username and strong password has just been reduced to a phone number and
numeric value. Although low tech, an attacker could simply enter
several phone numbers to see which ones are registered to use the
WAP/Mobile HTML site. Furthermore, most WAP/Mobile HTML sites give
verbose error messages (again, for a strong user experience but bad
security practice), so entering the incorrect mobile number will let the
attacker know that a number has not been registered. The attacker can
then enter the next number on their list until they receive an error
message that states the PIN is not correct instead of an error message
that says the phone number is unregistered. Once they have identified a
valid phone number that has been registered already, the attacker now
has to brute-force the PIN.
Admittedly, brute-forcing a weak
PIN is not the full responsibility of the banking/e-commerce site, but
how many users will simply use “1234” if they are required to have
numbers only and four values? Further, how many users will simply use
their seven-digit phone number as the password, which still fits into
the number-only restriction of four to eight values. The examples could
go on, but with a key space drastically reduced from A–Z, 0–9, and
special characters to 0–9 only, the likelihood of an attacker hijacking a
user’s account by brute force significantly increases. A possible
mitigation to brute-forcing weak PINs is for the organization to enforce
a password policy different from its online web application. For
example, the organization could mandate that the account is locked out
after three failed attempts. It could also reject physical keypad
sequences such as 2580 and repeating numbers, and it could restrict
certain numbers such as the seven-digit phone number or the last four
digits of the phone number. Each of these steps would help reduce the
basic brute-force attack from being successful.
It should be noted that some
WAP/Mobile HTML sites provide limited functionality, often just one or
two functions with little account information available; however, the
ability to buy/sell items or transfer dollars is available in most of
these sites, and this is likely to increase in functionality rather than
decrease (at least one major bank has full functionality with only a
four-digit number PIN). Regular PC-based banking/e-commerce websites had
very limited capabilities as well when they were first introduced and
quickly blossomed into full-fledged web applications, but the
enforcement of strong authentication lagged behind here too.
Adding to the “user
experience versus security tradeoff” theme, another avenue of exposure
is the crossover use of SMS and WAP/Mobile HTML applications. For
example, some WAP/Mobile HTML sites allow the use of SMS to retrieve
sensitive information. The general idea involves using a predefined
destination number (registered earlier in the web application) and
sending messages with specific words in them, such as balance, transactions, history, status, and accounts.
The receiving entity then returns specific information back to the
user, based on the request. Obviously, the use of SMS is important if
non-PDA phones are used because e-mail is
not really a strong option. After a mobile device is registered (that
is, the user has registered their mobile phone number and a correlating
PIN using the regular web application), the site allows the user to send
SMS messages to a specific number and retrieve certain data, such as
account balances and transactions. During this process, a user is not
challenged with a user ID or password/PIN, but is simply verified with
the caller ID value. For example, sending an SMS message to a predefined
number (assigned by the bank or e-commerce organization) will return an
account balance as long as the caller ID value is correct.
The key control here is the
caller ID, which is thought of as a trusted value. However, a simple
search on spoofing/faking an SMS message will turn up a lot of results
(this can also be done using an Asterisk PBX). Hence, if a handset/phone
number has been registered to receive/send information using SMS, an
attacker can simply spoof the caller ID, send an inquiry to the
known/predefined phone number, and then get the legitimate user’s
sensitive information (such as their bank balance). One might argue that
a handset must be registered first, but that should not be considered a
protection layer because sending 20,000 SMS messages, where 10,000 are
unregistered, does not affect a focused attacker much. Furthermore, any
information that is given to the user, whether it is an account balance
or a trusted/unique URL, based on the caller ID value should be not
considered trusted. For example, some organizations will give a unique
URL to every user that must be used with a valid PIN to access a
WAP/Mobile HTML site. Unlike with SMS, the PIN is required to enter the
mobile site; however, the unique URL can be obtained over SMS. Similar
to the “balance” request, an attacker can send a request via SMS for the
unique URL for any victim. Once the attacker has the unique URL by
spoofing the caller ID, they can then begin the process of brute-forcing
the PIN. Either way, using SMS to identify a user is very difficult and
should not be considered the most secure option.
Encryption
The use of Secure Sockets Layer
(SSL) and/or Transport Layer Security (TLS) is a critical aspect of
online security. SSL/TLS is used often by web applications to keep
sensitive information private over the Internet, bringing
confidentiality and integrity to HTTP (via HTTPS). The need for
transport security, via SSL/TLS, between a user’s mobile device and its
destination is equally important, as a growing number of sensitive
online activities take place on the mobile device and not the PC. This
section will review the use of encryption in both WAP 1.0 and WAP 2.0.
WAP 1.0
In
the early days of the mobile WAP world (WAP 1.0), TLS was used, but not
end to end. WAP 1.0 used a three-tiered architecture, including the WAP
mobile device, which in turn used a WAP browser, a WAP gateway (also
known as a WAP proxy server), and the web/application server on the
Internet. WAP 1.0 mobile devices mostly spoke Wireless Markup Language
(WML), which is similar to HTML. The WAP gateway would translate HTML
from the web/application server on the Internet to WML for the WAP
browser on the mobile device. The use of the WAP gateway was fairly
important in the early days because it would encode/decode all the data
to/from application servers to fit the data, size, and bandwidth
restraints of the mobile devices. In terms of security, the WAP gateway
also played an important role. Due to the limited horsepower on mobile
devices (including bandwidth, memory, battery, and CPU), full TLS
connectivity between the mobile device and the web/application server
was not used. Instead, Wireless Transport Layer Security (WTLS) was used
between the mobile device and the WAP gateway, and SSL/TLS was used
between the WAP gateway and the web/application server (see Figure 4).
Before we go further, we
should pause and talk a bit about WTLS. WTLS is similar to TLS and
provides transport security between mobile clients and WAP gateways. It
is based on TLS, but is used for low-bandwidth data channels that would
normally not be able to support a full-blown TLS implementation. Similar
to TLS, WTLS provides confidentiality and integrity using standard
block ciphers and MACs.
The WAP 1.0/WTLS
architecture brought up several concerns for mobile users and security
professionals, due to the absence of full end-to-end security. The
process of converting communication between WTLS and TLS would occur at
the WAP gateway (encrypting/decrypting), making it an entity that
performs a man-in-the-middle attack,
although legitimately. This meant that sensitive information was left
in a plain-text format, either in memory or in cache, or even written to
disk, on the WAP gateway itself. Because the WAP gateway is an entity
that is owned and managed by an ISP, not by a bank or e-commerce
institution, the ISP would have access to plain-text data from any user
using their gateway. Although trusting every ISP in the world and their
WAP gateways may have looked great on paper, the idea did not float too
well with many sending and receiving entities. This scenario—known in
some circles as the “WAP gap”—was not an acceptable option to many
organizations because the ISP’s WAP gateway could see all the decrypted
information to/from the mobile device. Whether it is a hostile ISP or
simply bad practice, the idea of sensitive information being decrypted
and then reencrypted between two trusted entities did not sit well with
many banking institutions and e-commerce vendors.
SSL and WAP 2.0
Due to the security concerns of
the WAP gateway (WAP gap) and its legitimate use of a man-in-the-middle
attack, full end-to-end security was supported in WAP 2.0. In the WAP
2.0 world, the WAP gateway was no longer required and became an optional
device. Full TLS end-to-end encryption is supported between the mobile
device and the web/application server, due to HTTP 1/1 support. A WAP
gateway could still be used, but for optional supporting purposes such
as optimization. Its role became more similar to a standard proxy-type
device rather than a required translation device. With the full
end-to-end support of TLS between the mobile device and web/application
server, WTLS is no longer needed. Figure 5 shows an example of TLS connections in the WAP 2.0 architecture.
