Understanding WAP Security
at the hardware level, even when they nominally conform to a standard, and may
contain hard to test and buggy code. At the same time, the mobile phone industry
is driven by fashion, and time to market is king, so there is a real incentive not to
waste time on testing. And mobile phones are expected to interoperate freely
regardless of vendor. This reads like a recipe for disaster: how can you claim that a
system is secure if inadequate testing means that you can't be sure that it is working
as its designer intended, especially when it is working in conjunction with software
and hardware from another vendor?
Of course, WAP security issues don't end with the phone. A WAP enabled Web site
is a key part of a WAP solution, and all the security issues associated with Web sites
still apply (probably more so, in practice, because of the fashion hype and time to
market issues around WAP). Badly written CGI programs, for example, provide a
classic way in for Internet hackers and will probably be behind some exposures
for WAP Internet access too.
The Weakest Link
Nevertheless, the phone is, and will probably always be, the weakest link. It is easily
lost or stolen, and the capabilities of WAP (and broadband third generation mobile
phone technologies) mean that it is increasingly likely to be used for the storage of
valuable data of varying degrees of importance such as a list of customers, their
phone numbers and even what you expect to sell them. Phone PIN numbers are
some protection but these only consist of four numerics and many users don't
bother to use a PIN anyway. There is also the risk of industrial sabotage if your
competitor depends on a WAP enabled sales force, how effective will its salesperson
in your area be once you've nicked his phone? Don't get too hung up on WAP
security until you've done a proper risk/threat assessment for the system as a whole,
and, as usual, made sure that your security policy (and security awareness classes)
are WAP aware.
Nevertheless, physical WAP security is a factor in the threats facing you and you
have to prioritise these threats. The real issues with WAP security today are bad
enough, but experts like Chris Rouland, who is head of the ISS X Force security team
(see
www.iss.net
), think the potential for security exposure is far worse. He worries
about the intrinsic trust model in WAP, which means that if you compromise one
part of the distributed system then security as a whole is compromised, and he isn't
happy with the design of the WML language. As is so often the case, security appears
not to have been considered fully enough or early enough in the design but at least
security was considered in the design of WAP, which is a considerable advance on
the state of the art a few years ago.
Potential For Viruses
However, many of the threats associated with WAP remain potential threats for
now. Phone viruses are feasible, but space and processing power in a phone is
limited, and it will probably be hard to get them to reproduce efficiently there isn't
room in phones for bloatware with macro autorun facilities. Nevertheless, we
mustn't be too complacent there isn't room in a phone for sophisticated anti virus
scanners either. Companies are already talking about anti virus products for mobile
phones F Secure's Anti Virus for WAP Gateways Release 5.0 (see
www.fse
cure.com/news/2000/20000215.html
) apparently shipped early in 2001 but many
Phone viruses are
experts think this is a bit premature. F Secure itself (on the page referenced) admits
that there are no known instances of in the wild malicious code for WAP based
feasible, but space and
devices , but claims it is important to get the infrastructure prepared for when they
appear. F Secure's product sits on the WAP Gateway and monitors material being
processing power in a
downloaded to the WAP devices.
phone is limited, and it
Rouland also thinks that WML (Wireless Mark up Language), which is the WAP
equivalent of HTML, may be a problem, as it works differently to HTML and
will probably be hard to
programmers may not allow for this. For instance, he points out that it handles the
user interface by assigning variables in the telephone and then putting them in the
get them to reproduce
right place on the screen. The phones themselves, in current implementations,
cannot differentiate between public and private variables, and rely on the server to
efficiently.
clear variables in memory; if they don't, passwords etc can stick around in memory
where they can potentially be compromised.
Issue 131:June 2001
PC Network Advisor
File: B1423.2
page 10
Buying and Evaluating:Hardware
www.pcnetworkadvisor.com
< Next page >
New! The best sites for quality inkjet printer cartridges and the best sites for cheap inkjet cartridges