What is a Web Service?

In association with W3C Web Services, the W3C has defined a web service as follows:

 A web service is a software system designed to support interoperable machine-to-machine

interaction over a network.

 It has an interface described in a machine-processable format (specifically WSDL).

 Other systems interact with the web service in a manner prescribed by its description using SOAP
messages, typically conveyed using HTTP with an XML serialization in conjunction with other
web-related standards.

In short, a web service can be described as a service that:

 Is available over the Internet or private networks

 Makes use of a standardized XML messaging system

 Is platform and language independent

 Is self-describing through a common XML grammar

 Is discoverable through a simple find process.

Characteristics of Web Services

 XML-Based

 Loosely Coupled

 Coarse-Grained

 Ability to be Synchronous or Asynchronous

 Supports Remote Procedure Calls (RPCs)

 Supports Document Exchange

Components of a Web Service

Over the past few years, the following primary technologies have emerged as worldwide standards that
make up the core of today's web services technology.

 XML-RPC

 SOAP (Simple Object Access Protocol)

 UDDI (Universal Description, Discovery, and Integration)

 WSDL (Web Services Description Language)

XML-RPC

 The simplest XML-based protocol for exchanging information between computers.

  Requests are encoded in XML and sent via HTTP POST.

 XML responses are embedded in the body of the HTTP response.

 Platform-independent.

 Allows diverse applications to communicate.

o A Java client can speak XML-RPC to a Perl server.

SOAP

 SOAP stands for Simple Object Access Protocol.

 It is an XML-based protocol for accessing web services.

 A W3C recommendation for communication between applications.

 Is XML based, so it is platform independent and language independent.

WSDL

 WSDL stands for Web Services Description Language.

 It was developed jointly by Microsoft and IBM.

 It is the standard format for describing a web service.

 Basically, an XML document containing information about web services such as method name,
method parameter and access information.

 An XML based protocol for exchanging information in distributed and decentralized

environments.

 WSDL is a part of UDDI and acts as an interface between web service applications.

UDDI

 UDDI stands for Universal Description, Discovery, and Integration.

 An XML based framework for describing, discovering and integrating web services.

 A directory of web service interfaces described by WSDL, containing information about web
services.

 An open industry initiative allowing businesses to find and explore each other and define how
they interact over the Internet.

Web Service Architecture

Web Service - Roles

There are three major roles within the web service architecture.

 Service Provider
 o The provider of the web service: Implements the service and makes it available on the
Internet.

 Service Requestor

o Any consumer of the web service: utilizes an existing web service by opening a network
connection and sending an XML request.

 Service Registry

o A logically centralized directory of services.

o The registry lays out a central place where developers can publish new services or find
existing ones.

Web Service Protocol Stack

The web service protocol stack provides a window for illustrating the web service architecture. At
present, the stack has four main layers:

 Service Transport: Handles the transportation of messages among applications.

o Currently, this layer includes HyperText Transport Protocol (HTTP), Simple Mail Transfer
Protocol (SMTP), File Transfer Protocol (FTP), and Blocks Extensible Exchange Protocol
(BEEP).

 XML Messaging: Facilitates the encoding of messages in a common XML format so that
messages can be comprehended at either end.

o Currently, this layer includes XML-RPC and SOAP.

Web Service Protocol Stack

 Service Description: Facilitates the description of a public interface to a specific web service.

o Web Service Description Language (WSDL) handles service description.

  Service Discovery: Centralizes services into a common registry and provides easy publish/find
functionality.

o Universal Description, Discovery, and Integration (UDDI) handles service discovery.

The Overarching Concern

Security is considered to be an overarching concern because almost everything in the digital world
demands some protection from the ever - increasing threats and challenges at some point in time.

For example, in the domain of web services

 The security of SOAP messages need to be ensured

 WSDL files may have to be protected against unauthorized access

 Firewall ports may require strategies to handle heavy loads and monitor web service messages,
and so on.

Since interoperability is a key characteristic of web services, while security mechanisms are added to
web services it has to be ensured that the execution environment technologies remain operational.

Web Service Security

Technopedia defines Web Service Security as:

Web Services Security (WS Security) is a specification that defines how security measures are
implemented in web services to protect them from external attacks.

It is a set of protocols that ensure security for SOAP-based messages by implementing the principles
of confidentiality, integrity, and authentication.

There are three specific security issues with web services:

 Confidentiality

 Authentication

 Network Security

Confidentiality

How can confidentiality be ensured when a client sends an XML request to a server?

The answer lies in the points below.

 XML-RPC and SOAP primarily run on top of HTTP.

 HTTP supports Secure Sockets Layer (SSL).

 SSL can be used to secure communication.

 SSL is a widely deployed proven technology.

Challenges to Confidentiality
A chain of applications may be associated with a single web service.

 For instance, The services of three applications may be tied together by a single large service.

o In such a scenario, SSL may not be adequate and the messages will have to be encrypted
at each node in the service path. Hence each node acts as a potential weak link in the
chain.

o One promising provision to the issue is the W3C XML Encryption Standard.

 The W3C XML Encryption Standard provides a framework for encryption and
decryption of XML documents.

Authentication

How can a user who connects to a web service be identified? Is the user authorized to use the service?

The following options can be considered but there is no clear consensus on a strong authentication
scheme.

Though there is no coherent consensus on a secure authentication scheme, the following points may be
considered.

 Services can be protected in a similar manner as HTML documents are currently protected since
HTTP encompasses in-built support for Basic and Digest authentication.

 SOAP Digital Signatures exploits public key cryptography to digitally sign SOAP messages
enabling clients/server to authenticate the identity of the end user.

Network Security

Network security has been the subject of speculation with no easy solutions to the problem.

To filter out SOAP or XML-RPC messages:

 One option is to filter out all HTTP POST requests that set their content type to text/XML.

 Another possibility is to filter the SOAPAction HTTP header attribute.

Wireshark and Fiddler are tools that can be used to monitor HTTP traffic.

WS Security: Core Concepts

Two basic security mechanisms are employed by web services to handle security risks:

 Signing

 Encrypting Messages

These mechanisms are used to ensure data integrity, confidentiality, checking token and ticket
information to set the seal on authentication and authorization.

These mechanisms are usually incorporated in combination to handle various aspects of security as a
broader picture of risks needs to be analyzed to tackle them efficiently.
WS Security Headers

WS-Security headers, which may include mechanisms for authorization, authentication, encryption,
and signature can be added to SOAP messages enabling service providers to verify the credentials of the
service requester.

Authentication and authorization information from the requester is usually represented in the form
of tokens.

Hence, efficient strategies to communicate and coordinate security information(tokens) between

communicating parties need to be enforced.

WS Security: Encryption

Before a message is transmitted, an encryption algorithm can be used to encrypt the messages. The
encrypted message can then be decrypted at the receiver's side before processing.

Encryption is the process of transforming data into an unintelligible form so that an unauthorized person
cannot make sense of the underlying message.

Encryption enhances the security-related with authentication and authorization of data (such as a
password), even if the content of the SOAP body isn't encrypted.

The details of encryption such as the algorithm used may be embedded in the WS Security header.

WS Security: Encryption
Other extended technologies, such as reliable transactions and messaging may be used in combination
with the basic security mechanisms to enhance the security of the overall system.

Additional messages may be required by transaction processing technologies to facilitate coordination

among transaction protocols which demand security to deter disruption.

WS Security: Identity Management

The identity of a web service requester is crucial in establishing trust between the web service
requester and provider since access controls for services, resources. Alternatively, devices are based on
the identity of the requester.

Since web services can span across departments and enterprises, managing identity for web services can
be a complex task.

Identity management can be performed locally, departmentally, or within an organization.

Sometimes identity management will have to be performed under a broader scope, such as a corporate-
wide LDAP solution or the Microsoft Active Directory.

When identities have to be precisely managed across the Internet or enterprises, the need for trust
increases so does the level of administrative difficulty.

WS Security: Authentication

Web service requesters can incorporate authentication information using username-password

information in SOAP headers which the service provider can verify against its authorized directory of
usernames and passwords.

The username and password information can also be sent through HTTP without the use of a SOAP
header.

Further refinement of this model may be carried out by the provider to reinforce authorization checks
for access specific services or certain data resources.

Authorization may sometimes be carried out based on specific roles such as admin, manager, or clerk
which is typically managed by the service provider.

WS Security: Digital Signature

In Digital signatures, a message digest is signed using a private/public key pair.

A hash algorithm is used to create a message digest, and an encryption algorithm is used to sign the
digest with the private key.

At the receiver's end, the public key is used to decrypt the signature and recomputes the message for
comparison.
If the results don't match, it can be concluded that the messages have been altered and the provider can
infer that the message has been tampered with.

Though for signing asymmetric keys are widely used, to compute the signature, symmetric or
asymmetric algorithms can be used.

Finding the Right Balance

As with any application, a sound equilibrium between business requirements, performance, security,
and ease of administration needs to be established even for web services.

Security techniques carry a performance price not only in terms of additional processing overhead while
executing a service but also to the professionals who design, develop, and administer them.

Encryption encompasses an implicit overhead considering the time involved in the process.
Incorporation of a username/password on each message further adds to processing overheads.

Hence, it is trivial not only to perceive the solutions provided by the technology but also to consider the
overhead costs while exploring less expensive but equally efficient solutions.

Challenges and Threats to Web Service Security

Since they represent a messaging and abstract interfacing layer, Web services cannot (and should not)
exploit some of the security mechanisms used by the underlying platforms on which the web services
run.

Hence, operating system-level protections such a file or device protection, memory protection or
network level protection should not be replicated in the web services environment.

Generally, security solutions should be implemented via the transport layer, the Web services layer and
the data layer to establish stronger protection against the ever-increasing threats and challenges.

The Expectation

In the domain of web services the security solutions should be mapped into and out of the underlying
execution environment to ensure the following:

 Enforcement of the security policy defined.

 When the assurance to security policy cannot be properly defined: the proper maintenance of
an audit log which contains entries of the failure or policy breach

Message Interception

The possibility of intercepting and decoding SOAP messages draws in security threats that must be
defended against when deploying Web services.

Web services messages are usually transmitted as plain text, which can easily be intercepted and read
(Unless they are specifically encrypted).
Message Interception: The Threats

Message interception provokes the following threats:

 Content modification which could affect all or part of the message body/headers.

 Addition of bogus information into the message body/headers.

 Modification/Alteration of message attachments.

 Unauthorized access to confidential, sensitive information.

Use of encryption techniques and digital signatures can help tackle threats against message interception
thus ensuring confidentiality and integrity.

Person in the Middle Attacks

SOAP messages can be routed through intermediaries and intermediaries have the access rights to
examine the messages to process headers.

Compromised intermediaries pose a severe threat to WS Security, as the communication between the
end-users can be intercepted without their knowledge.

Mutual authentication techniques provide a solution to this type of threat.

Signed keys or derived keys further enhance the protection.

Spoofing

Spoofing poses additional challenges to security as the attacker presumes the identity of a
trusted/authenticated entity to bypass the security system.

Spoofing aims at deceiving the target to believe the authenticity of the communicating entity.

Spoofing usually opens the door to user in other forms of attacks such as message forgery.

Mutual authentication techniques can be exploited as a solution against this type of threat.

Replay Attacks

In a replay attack, a malicious attacker intercepts a message and replays it back to the receiver.

Replay attacks could be exploited to invoke fraudulent transactions or to collect confidential information

Strong authentication techniques along with message time stamp and sequence numbering as a shield
against this type of threat.
Denial-of-Service Attacks

Unauthorized attackers or intermediaries who manage to intercept a SOAP message successfully can
provoke a denial of service attack by repeatedly resending it to overload the web service execution
environment.

Such a scenario could cause services to be denied to legitimate services/users.

An attacker who manages to get hold of the address can also blast a ton of messages to the web service
to interrupt services.

Even if the messages are rejected, the site can get overloaded with error processing.

XML Bomb

Technopedia defines XML Bomb as

An XML bomb is a piece of XML code that is syntactically valid and correct but can cause a program that
compiles or runs it to crash or hang.

The security level of a server can be tested using XML Bomb.

 Within an HTML code, an XML code is either parsed internally or referenced as an external file
that is directed to a server.

 Basically, a typical server without enough protection is expected to crash with this attack.

An XML bomb exploits three properties of XML: entity substitution, nested entities and inline DTDs,
which results in "data explosion". Hence the "bomb" in the name.

Understanding the Security Architecture

It is vital to examine the security challenges and threats to web services within their overall architectural
background and analyze solutions based not simply on a particular technology but also by reviewing the
overall solution context.

That is, you cannot just say “use SSL” without having a sound understanding of the threat you are trying
to handle and without understanding the overall security setting into which you would like to deploy SSL.

SSL may be sufficient, but it may not.

Heterogeneous security solutions must often be used simultaneously in order to extend a

comprehensive solution to the prominent security concerns, and hence it is crucial to understand how
the technologies work together.

Securing the Communication Layer

The communications transport layer is the first level that needs to be secured. In the domain of Web
Services, it is almost always TCP/IP, and this is the case when HTTP is used.
Firewalls prevent access by programs at unauthorized addresses by mapping a publicly known IP address
to a different IP address on the internal network, hence establishing a managed tunnel.

Web services can handle existing firewall configurations, which most often implies that improved
protection has to be included in firewalls to analyze incoming SOAP traffic and log any problems.

Another prominent solution involves the exploitation of XML firewalls and gateways that are efficient in
recognizing Web services formats and conducting initial security checks.

IP Layer Security

Security methods for the Internet include the IP layer with IP security (IPsec).

IPsec presents packet-level encryption and authentication and is usually implemented at the operating
system level.

IPsec is a provision accessible to all applications using the Internet, including Web services.

However, this implies that the IPsec connection is a part of a separate security setup between the
communicating entities.

Notably, for Web services to use IPsec, the IPsec communication session has to be established before
invoking a Web service, typically by the user or the transport, since nothing in the Web services layer can
be used to establish an IPsec session.

IP Layer Security

IPsec is most often used in Virtual Private Network (VPN) applications and between firewalls, which
many companies exploit to secure the communications between corporate systems and remote users.

Other VPN technologies are also widely adopted as a foundation for security in Web services invocations,
just the way they are used by any other Internet-based application.

Transport Layer Security

The next level to be considered is transport layer security.

Typically, this is ensured by Secure Sockets Layer/Transport Layer Security(SSL/TLS, commonly referred
as SSL), which is often seen on the Web as HTTPS.

This security level can be enforced in the network application, and Web services can directly and easily
exploit it by choosing HTTPS as a transport.

Implementations of SSL for other transports, such as IIOP and RMI/IIOP, also present the potential for
Web services to exploit this important privacy mechanism when employed over other transports

SSL in WS-Security: The Pros

 SSL provides encryption and strong authentication and may be enough for many applications.
  SSL authentication can be exploited to provide strong, mutual authentication - much stronger
than HTTP Basic, HTTP Digest, or WS-Security username token authentication

SSL in WS-Security: The Cons

 SSL is transport-based rather than application-based, and hence secures the network nodes
instead of the service requester or provider.

 SSL provides message confidentiality, authentication, and message integrity, but these
capabilities are restricted to the transport level, and cannot be extended to the application
level.

 SSL also does not provide any protection for XML data in storage.

 It does not provide direct support for any of the advanced authorization checks such as role-
based authorization that may be required by many applications.

o However, it is possible to map the SSL strong authentication information to a local

principal and use that in an application-defined role-based authorization scheme to
determine access privileges.

Transport Layer Security: Authentication

Basic authentication techniques (such as basic username/password), may not be sufficient for Web
Services.

Passwords could be encoded using Base64 or some simple obfuscation algorithm even without SSL.

 However, obfuscation does not provide true encryption and hence is not very secure.

 If a potential attacker figures out the algorithm or encoding mechanism used for the
obfuscation, the message can easily be compromised.

Additional, stronger authentication mechanisms include:

 At the transport level: HTTP Basic, HTTP Digest, and SSL.

 At the application level: Username/password, X.509, Kerberos, SPKM, SAML, and XrML.

kerberos

Message Level Security

Message-level security is the next level of security above the transport level in which the WS-Security
framework and associated specifications provide the security protections.

The WS-Security framework defines SOAP headers incorporating the necessary information to protect
messages.

The WS-Security specification defines the security header for SOAP messages and components of the
header (including what can be included).
The contents of the SOAP security header and the associated processing rules are defined in the
associated specifications.

The Challenges

The use of Web services imposes additional challenges to security as Web services exhibit access to
programs and data stores.

Moreover, complex Web services may be spread across multiple network locations discovered
dynamically or may constitute a larger interaction.

Since sensitive information could be passed from one service to another, Web services require an end-
to-end security model.

Interactions in a Web service could involve multiple parties using discrete security-related technologies.

WS-Security Framework

WS-Security (Web Services Security) is the name of a set of specifications that enhances SOAP message
headers to integrate solutions to common security threats, particularly those associated with Web
services messaging.

The major motivation

WS-Security must define how XML Encryption and XML Signature should be used with SOAP as SOAP is
a variant of XML documents devised for messaging and interoperability.

WS Security Protects Against:

 Message alteration: By including digital signatures for all or parts of the SOAP body and the
SOAP header.

 Message disclosure: By supporting message encryption.

WS-Security Framework

Other Uses

 Preserves message integrity by exploiting of strong key algorithms.

 Authenticate messages by exploiting various token mechanisms such as Kerberos and X.509

WS-Security Specifications

 SOAP Message Security.

 Username Token Profile.

 X.509 Token Profile.

  Profiles for the use of other technologies with the framework such as SAML, Kerberos, and XrML

WS-SecurityPolicy

WS-SecurityPolicy is a policy assertion language that can be used within the WS-PolicyFramework

An XML-based assertion associated with a Web service endpoint or WSDL file can be developed
with WS-SecurityPolicy using WS-PolicyAttachment

WS-SecurityPolicy association can be discovered by a service requester using the WS-

MetadataExchange protocol

 Otherwise, a URL pointing to the XML file in which the WS-SecurityPolicy assertion is stored has
to be dereferenced.

Decoding the WS-SecurityPolicy assertion helps the service requester understand the security features
that are required by the service provider.

WS-SecurityPolicy: An Example

<wsp:Policy

xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"

xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext">

<wsp:All>

<wssp:Integrity wsp:Usage="wsp:Required">

<wssp:Algorithm Type="wssp:AlgSignature"

URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

</wssp:Integrity>

<wssp:SecurityToken>

<wssp:TokenType>wsse:X509v3</wssp:TokenType>

</wssp:SecurityToken>

</wsp:All>

</wsp:Policy>
The example above illustrates that the provider demands message integrity using the referenced XML
Signature algorithm and demands authentication using X.509 tokens.

WS-Trust

At times, the service provider and requester may have to communicate out of band (i.e., out of the
customary Web service invocation message exchange) to interchange security credentials.

For instance, before sending a message, a requester may have to obtain a service provider's public key
for encryption.

The WS-Trust specification defines a set of rules for evaluating and arbitrating a trusted relationship such
as this.

WS-Trust establishes a protocol for:

 Issuing, validating and renewing security tokens.

 Evaluating or arbitrating trust relationships.

WS-Trust defines the process of exchanging and arbitrating security tokens so that the requester can gain
the necessary security information to construct trusted messages.

WS-Trust

As illustrated in the image above WS-Trust elucidates a SOAP message exchange protocol based on
which a service requester and provider can communicate with each other to exchange authorization and
authentication credentials.

WS-Trust

The security model described in WS-Trust is based on a process in which a Web service provider can
insist that an incoming message from a requester establish a set of credentials (userId/password,
permission, key, capability, etc).
WS-Trust establishes the message exchange pattern and format of the information credentials that may
have to be exchanged between the requester and provider in order to satisfy the policy assertions.

 Security tokens are requested using the <RequestSecurityToken> message described in the WS-
Trust specification.

 Security tokens are returned using the <RequestSecurityTokenResponse> message described in

the WS-Trust specification.

WS-SecureConversation - The Web services protocol for creating and sharing security context

WS-SecureConversation elucidates a shared security background across multiple message exchanges.

It defines a new security context background for the <wsse:Security> header block, and it describes a
binding for WS-Trust.

Instead of having to incorporate the same security credentials in each SOAP message, a provider and
requester can use WS-SecureConversation to negotiate sharing a common security context.

For example:

<SecurityContextToken wsu:Id="...">
<wsc:Identifier>...</wsc:Identifier>
</SecurityContextToken>

WS-SecureConversation

As illustrated in the image above, WS-SecureConversation describes a SOAP message protocol for
establishing and propagating common copies of security context at the provider and requester nodes.

The shaded areas illustrate shared security context used across multiple message exchanges.
WS-Federation

WS-Federation describes the process of establishing trust relationships across security domains.

WS-Trust presumes a single security domain within which the service requester authenticates with the
service provider’s authentication service.

WSFederation elucidates a binding of WS-Trust that facilitates a service provider to handle

authentication credentials that originate from a different security domain.

Since Web services can span across multiple domains, problems related to authentication and access
control of identities has to be handled for various domains.

The WS-Federation specification illustrates a message exchange protocol that service providers and
requesters can employ to establish a federation of security domains spanning multiple trust boundaries.

The Federation of security trust domains can be accomplished by using WS-Security, WS-
PolicyAssertions, and WS-Trust in combination.

Particularly, WS-Federation takes WS-Trust a step further and initiates a mechanism for interchanging
credentials across trust boundaries, not just within a trust boundary.

 Security tokens are requested using the <RequestSecurityToken> message described in the WS-
Trust specification.

 Security tokens are returned using the <RequestSecurityTokenResponse> message described in

the WS-Trust specification.

The Security Assertion Markup Language (SAML) from OASIS is an XML application that aims to assist
single sign-on and propagate authorization information.

For example, SAML helps a user to log on to a Web site once and then access affiliated Web sites without
having to log on again.

The WS-Security SAML profile describes the process of using SAML with SOAP, but SAML can also be
used independently of SOAP and WS-Security, if necessary.

To enable single sign-on, SAML defines three basic components: assertions, protocol, and binding.

Data Level Security

Two of the fundamental security specifications for ensuring the protection of Web services data are XML
Signature and XML Encryption as Web services specifications are applications of XML.

For example, WSDL files can be protected against unauthorized access by encryption and WSDL files can
be protected against tampering by signing them.

It is particularly important to give a thought to using these XML security technologies when:

 The XML data has to be protected outside the scope of a SOAP message.
  When the metadata of Web services need to be protected from unauthorized access.

XML Encryption

SSL can be used to encrypt XML payload when carried over HTTP, but at times it might not be enough.

It is vital to have specific strategies for the encryption of XML documents when transmitting XML over
other transports, possibly over multiple modes of transport, or while storing XML documents in a
database or a file.

During encryption, the EncryptedData element described in the XML Encryption specification replaces
the content or element in the encrypted version of the XML document.

Encryption can be nested to any level.

The entire document (except the encryption headers) or any specific element within the document can
be encrypted.

Selective Encryption

Selective encryption can be practically exploited when only a part of a document needs to be encrypted.

Tags, as well as the data contained, can be encrypted to achieve complete confidentiality of information.

For example, hiding a <creditcard> tag inside a <CipherData> tag.

An Example

<?xml version='1.0'?>

<PaymentInfo xmlns='http://www.iona.com/artix/paymentService'>

<Name>Eric Newcomer</Name>

<CreditCard Limit='50,000' Currency='USD'>

<Number>5555 5555 5555 5555</Number>

<Issuer>Example Bank</Issuer>

<Expiration>04/02</Expiration>

</CreditCard>

</PaymentInfo>

Above is an example of a plain, unencrypted data.

The Encrypted Form...

The encrypted form of the data is as follows:

<?xml version='1.0'?>
 <PaymentInfo xmlns='http://www.iona.com/artix//paymentService'>

<Name>Eric Newcomer</Name>

<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'

xmlns='http://www.w3.org/2001/04/xmlenc#'>

<CipherData>

<CipherValue> A23B45C56...</CipherValue>

</CipherData>

</EncryptedData>

</PaymentInfo>

 CipherData element contains the encrypted data.

 If an application needs all information to be encrypted, the entire document can be encrypted as
an octet sequence.

To Note

 The <EncryptedData> element cannot be nested, but an <EncryptedData> tag can be applied at
the same level as another <EncryptedData> tag, resulting in an already encrypted data to be
encrypted again.

 The EncryptionMethod is basically a secret key mechanism such as RC4 or 3DES, RSA public key
algorithm, etc depending on the level of protection required.

 All the encrypted items within a document are contained in a reference list.

 A URI can be employed to point to the encrypted data

XML Signature

XML Signature can be used to ensure that the document or part(s) of the document have not been
tampered with maliciously before reaching the recipient

It is not the obligation of the receiving application (For example, a Web service provider) to understand
what has been signed, but if it can understand the signed part of the document, the signature can be
analyzed to ensure that the contents have not been altered, thus ensuring the authenticity of the
document's author.

Applications may sign multiple data objects, some of which may not be XML.

An XML Signature can be applied to the content of one or more parts within an XML document.

XML Signature has also been designed to support binary objects and multimedia types in addition to
XML elements and attributes.
XML Signature

The data objects are canonicalized and digested before being sent.

 Digesting applies a hash algorithm over the data object.

 Canonicalization removes all white space and restructures the document based on
the canonicalization algorithm.

Before signing data, canonicalization of data is done to ensure that the same results are obtained every
time.

Web Security Testing

It usually takes more than using a tool in WSDL to analyze security issues to precisely test a Web service.
However, not much effort and time has been invested in this area by the security communities.

The traditionally exploited testing techniques and testing methodologies may not be efficient enough to
handle the ever-increasing real-world threats and vulnerabilities facing Web services.

Lack of proper testing environments, tester expertise and practical solutions to testing makes the testing
process challenging.

OWASP Web Service Testing Methodology

The OWASP testing guide v4 elucidates techniques for testing Web services. They are as follows:

 WS Information Gathering – The WS entry point, as well as the communication schema are
determined

 Testing WSDL – Testing the WSDL can be done once the WS entry point is determined.

 XML structure Testing – If the XML is not well-formed, it will fail once parsed on the server side.
The structure of the XML needs to be tested to make sure that it runs the entire XML message
from top to bottom in a serial way to ensure that the XML is well-formed.

OWASP Web Service Testing Methodology

 XML Content Level Testing – Typically the content-level attacks target the server that hosts a
web service and any applications which are used by the service.

 HTTP GET Parameters / REST Testing – Several XML applications are raised by sending them as
parameters through HTTP GET queries. Attackers can pass malicious content through the HTTP
GET string to attack the web services.

 Naughty SOAP Attachments – Various risks are involved in processing the server attachments
and redeploying the file to the clients. This section tests the attack vectors for Web servers that
accept attachments.
Penetration Testing of Web Services

The penetration testing of Web services demands the following as prerequisites:

 Sample API file ( WSDL/ SOAP, etc.)

 Sample request/ response ( to understand the values and data exchanged)

 Entry points/ URLs

WS Penetration Testing: Tools

The following tools may be exploited to perform Web services penetration testing:

 Fiddler
 Burp Suite
 Acunetix/IBM Security AppScan
 ZAP Proxy
 Curl
 SOAP UI
Automated Testing Tools

 SoapUI Pro
 OWASP ZAP
 HP Webinspect
 BM AppScan
 WSMap
 WSBang
Manual Testing Tools

 Soap UI Free
 Burp Suite Pro
 Postman ( with Burp)
Extensions

 SAML Editor
 SAML Encoder / Decoder
 WSDL Wizard
 Wsdler
 SOA Client

Test Cases to Find in Web Services

• Fuzzing • XSS /SQLi/ Malformed XML

• File Upload • Xpath Injection

• XML Bomb (DoS) • Authentication based attacks

• Replay attacks • Session fixation

• XML Signature wrapping • Session timeout

• Host Cipher Support/ Valid Certificate/ Protocol Support

• Hashing Algorithm Support

Takeaways

 Web Service Security Testing Cheat Sheat

 Testing WSDL

 SoapUI

HTTP, FTP, SMTP are included in Service transport layer of the Web service protocol stack?

SSL does not provide direct support for role-based authorization.

IPSec is usually implemented at the operating system level.

Authentication and authorization information from the requester is usually represented in the form of
Tokens