Opinion: How to
secure Web services
Simson
Garfinkel, Computerworld
12/24/2003
08:00:11
Securing
Web services is easy: All you have to do is secure
your Web server, secure every message flowing in and
out of your server, secure every application that
has anything to do with SOAP and XML, and secure the
business operations and practices driving the whole
thing.
OK,
OK. So securing Web services isn't that easy--in
fact, it's downright difficult. So, in the
traditional fashion of software development--where
the market demands features now and security
later--many businesses are tempted to deploy Web
services that aren't tremendously secure (and many
probably do).
In
one sense, it could be argued that that isn't so
terrible. Most of the potential security problems
with Web services won't immediately be found by
people with automated scanning tools if they're not
yet trained to find the problems. But Web services
security holes can be easily exploited by
knowledgeable insiders--people interested in hacking
for revenge or monetary gain. The insider threat is
always at least as serious as the anonymous hacker
threat. So ultimately, it pays to properly secure
these services.
Since
Web services is built on top of a Web server, the
first step in securing Web services is to secure the
server itself. Vulnerabilities have been found
during the past year in both Microsoft IIS and the
Apache Web server. So no matter which Web server you
run, make sure you have installed all of the
necessary security updates.
Next,
audit your server so there are no unauthorized or
legacy CGI, ASP or PHP scripts. Confirm that raw
scripts can't be downloaded by people on the
Internet. If your Web service is based on a
database, make sure that the scripts don't contain
user names and passwords. Instead, put that
information in a separate file that's read by each
script when it starts up. Among other things, that
will make changing your passwords on a regular basis
easier.
Making
Connections
After
you secure your Web server, you need to worry about
how your Web services clients are going to connect
to it. Are you going to be making anonymous Web
services available over the Internet, or do you
intend to use Web services for high-value
transactions with your customers and suppliers? If
money or business reputation or potentially
confidential information is involved with your Web
services, you'll almost certainly want to combine
some form of authentication--to validate your
incoming connections--with some form of
encryption--to prevent unauthorized snooping on the
actual transactions.
If
you search for "securing Web services" on
the Microsoft product support website, you'll get a
nice set of articles on how to configure your Web
server for the SSL encryption standard and how to
install an SSL certificate.
There's
also a great article by Matt Powell titled
"Defending Your XML Web Service Against
Hackers." Key issues that Powell addresses are
spoofing, denial-of-service attacks and exploitable
bugs.
Powell
points to two issues to consider when creating Web
services: buffer overflows and SQL-injection
attacks. Buffer overflows are, of course, one of the
most common security problems on the Internet today.
They happen because a programmer has written a piece
of code that assumes some piece of data will never
be longer than, say, 256 characters.
To
exploit the bug, an attacker provides a block of
data that's much longer--say, 1,034 characters. Most
of the attacker's data is garbage, but at the block
is a small program. Because of the way the C
programming language is implemented, the attacker's
program can end up being executed by the Web server
itself, giving the attacker complete control of your
system. Avoid the problem by having your programmers
assiduously check the length of every string read
over the network--or by programming in Java, a
language that doesn't have buffer overflows.
Talking
Points
SQL-injection
attackers are more subtle. Short for structured
query language, SQL is the standard language for
communicating with structured databases. Most
database-driven Web services use information
provided by the Web services client to create SQL
statements. But if the application developer isn't
careful, a malicious client can put actual SQL
commands into the data stream. Unless the
application developer specifically quotes or
otherwise removes special characters from the data
stream, those commands can be passed along to the
database.
Even
if you have a secure Web server and a secure Web
services application, it's important to remember
that many of these services are nothing more than
glorified order-entry systems. Unless you have
additional controls on those orders, you can run
into more traditional security problems. Guard
against them!
For
example, many businesses have some kind of
fraud-detection system running on their credit card
processing engine, which means that
suspicious-looking transactions are blocked until
they can be manually reviewed. If you are accepting
XML-enabled purchase orders through a Web services
application, you should have suitable antifraud
systems in place on the Web service as well. Simple
systems establish a maximum number of dollars and
transactions per customer per month, and prohibit
certain items to be sent to certain geographical
regions (such as Nigeria) without explicit
authorization.
Web
services are increasingly being used for complicated
business negotiations, transactions and even
outsourced information processing. Already some Web
services provide credit rating, credit scoring and
loan application processing. Typically these are
business-to-business applications that are used to
enable consumer-facing Web servers operated by
commercial banks.
Subject
to Change
Alas,
as companies use Web services for increasingly
complex business transactions, they're going to be
covered by negotiated legal agreements written in
English. And, like all legal agreements, they'll be
subject to change. That can mean problems for
companies that want to rely on information exchanged
over Web services. In other words, a credit score of
580 might mean something different in January than
it did last July.
Is
the fact that different Web services results can
have differing interpretations a security issue?
Probably not. But in all likelihood, that issue is
going to be solved using the same mechanism as many
security issues--that is, through the use of digital
signatures.
For
example, a Web services request would include the
URL of the legal agreement under which the request
is made, and perhaps a cryptographic hash or digital
signature of that agreement, just so that the client
and the server can both be in harmony as to which
legal agreement is in force. Such issues will become
even more important as companies begin to use the
same Web services to offer different services to
different partner organizations under different
terms and conditions.
Many
SOAP (simple object access protocol) and XML
security issues are being addressed by the World
Wide Web Consortium's XML Signature and XML
Encryption projects, and by the Organization for the
Advancement of Structured Information Standards SOAP
Message Security standard. Essentially, these
standards provide for a uniform way of assigning
time stamps to messages, to prevent replay attacks;
of computing cryptographic hashes of SOAP messages,
to protect their integrity; of digitally signing the
messages, to establish their authorship; and of
encrypting the messages, to prevent eavesdropping as
the messages are sent over the Internet.
Observant
readers will note that several of the goals of the
standard--specifically encryption and digital
signatures--are already provided by Web servers that
require SSL encrypted client-side certificates. The
advantage of creating a new signature standard for
Web services is that SSL protects only the
transmission--it doesn't actually protect the data.
With XML signatures or SOAP Message Security, the
digital signature remains as part of the SOAP
message and can be verified again. You can find out
more information about these standards at www.w3.org
and www.oasis-open.org.
Of
course, you can deploy completely useful Web
services using only basic user name and password
authentication, no encryption--and never have a
single security problem. But if you are that
reckless, be sure to keep it a secret.
Finally,
a Plea
When
a spate of mass-mailing computer worms and viruses
hit this past August, my e-mail inbox was flooded.
But my inbox wasn't filled with copies of a virus;
it was filled with e-mail messages from antivirus
systems all over the world telling me that I had
sent them a virus, and that the message had been
filtered.
My
computer was never infected with a virus. Other
people's computers were infected, but they were
sending e-mail messages with faked "from"
addresses. Years ago it made sense to send e-mail to
people who were sending out virus-infected e-mail
messages. But those days have long passed. Today the
vast majority of worms and viruses fake the return
address. Antivirus systems that send out
notification e-mail messages merely compound the
problem.
On
one day I received more than 200 of these
notification messages--messages that were supposed
to be helpful. And I was one of the lucky ones;
someone I know from the MIT Media Lab received more
than 2,300 messages in one 24-hour period. If your
company's antivirus system is set up to send these
notification messages, please change the
configuration. Otherwise, your antivirus system is
just making the problem worse.
|
