BUILDING SECURED WEB SERVICES
Overview
Web services are used by an
increasing number of companies as they expose products and services to customers
and business partners through the Internet and corporate extranets. By exposing
to the external world it has its own potential threats.
Threats and
Counter Measures
Top
threats directed at web services are
1.
Unauthorized access
2.
Parameter Manipulation
3.
Network eavesdropping
4.
Disclosure of configuration data
5.
Message replay
Unauthorized
Access
Vulnerabilities
Counter
Measures
1.
No Authentication used
2.
Passwords passed in Plain Text in Soap Headers
3.
Basic Authentication used over an encrypted communication channel
Use
password digests in SOAP headers for authentication.
Use
Kerberos tickets in SOAP headers for authentication.
Use
X.509 certificates in SOAP headers for authentication.
Use
Windows authentication.
Use role-based authorization to restrict access to Web
services. This can be done by using URL authorization to control access to
the Web service file (.asmx) or at the Web method level by using
principal-permission demands.
Parameter
Manipulation
Vulnerabilities
Counter
Measures
1.
Messages that are not digitally signed to provide tamper proofing.
Digitally
sign the message. The digital signature is used at the recipient end to
verify that the message has not been tampered with while it was in transit
.
Encrypt the
message payload to provide privacy and tamperproofing.
Network
Eavesdropping
Vulnerabilities
Counter
Measures
1.
Credentials passed in PlainText in SOAP Headers
2.
No message level encryption is used
Use
Transport level encryption such as SSL or IPSec.This is appreciable only if
you control both endpoints
o
Encrypt the
message payload to provide privacy. This approach works in scenarios when
your message travels through intermediary nodes route to the final
destination.
Disclosure Of
Configuration Data
Vulnerabilities
Counter
Measures
1.
Unrestricted WSDL Files available for download from the web server
2.
A restricted web service supports the dynamic generation of WSDL and
allows unauthorized consumers to obtain web services characteristics
3.
Weak exception handling.
Authorize
access to WSDL files using NTFS permissions.
Remove WSDL
files from web server
Disable the
documentation protocols to prevent the dynamic generation of WSDL
Capture
exceptions and throw a SoapException or SoapHeaderException that returns
only minimal and harmless information.
Message Replay
Vulnerabilities
Counter
Measures
1.
Messages are not encrypted
2.
Messages are digitally signed to prevent tampering.
3.
Duplicate messages are not detected because no unique message ID is
used.
Use
Encrypted communication channel for example SSL
Use a
Unique message ID
Encrypt the
message payload to provide message privacy and tamper proofing.
Design
Considerations
1.
Authentication Requirements
2.
Privacy and Integrity Requirements
3.
Resource Access Identities
4.
Code Access Security
Authentication
Requirements
Please refer Authentication Section to get more
information.
Privacy and
Integrity Requirements
WSE provides integrity checking through digital
signatures, and it also supports XML encryption to encrypt sensitive elements of
the entire message payload. The advantage of this approach is that it is based
on the emerging WS-Security standard and that it provides a solution for
messages that pass through multiple intermediate nodes. The alternative is to
use transport level encryption through SSL or IPSec channels.
Resource Access Identities
We can use ASPNET process
account to access remote network resources such as SQL Servers that require
Windows authentication, by creating a mirrored local account on the database
server.
Code Access Security
Consider the trust level
defined by security policy in your target deployment environment. Web services
trust level defined by its <trust> element configuration, affects the
types of resources that it can access and the other privileged operations it can
perform.
Also, if you call a Web
service from an ASP.NET Web application, the Web applications trust level
determines the range of Web services it can call. For example, a Web application
configured for Medium trust, by default, can only call Web services on the local
computer.
Authentication
A number
of authentication schemes are available which are divided in three categories
mentioned below.
1.
Platform Level Authentication
2.
Message Level Authentication
3.
Application Level Authentication
Platform Level
Authentication
