Chapter 10

Securing Web Applications, Services,

and Servers
Gerald Beuchelt
Demandware, Inc., Burlington, MA, United States

1. SETTING THE STAGE these threat actors one may find a diverse crowd:
script kiddies, disgruntled employees, organized crime,
The development of a distributed hypertext system in the hacktivists, terrorists, or foreign intelligence agencies.
early 1990s at the CERN in Switzerland was one of the While their capabilities and credibility as threat actors
defining moments in making the Internet available to an may vary significantly, they are all credible source of
audience beyond academia and specialized communities. attacks against simple web sites such as nonprofit club
The combination of a simple, yet powerful transport home pages, or highly secured commercial targets such as
protocoldHypertext Transfer Protocol (HTTP)dwith a banks or e-commerce sites.
specialization of the Standard Generic Markup Language While web assets are typically more accessible than
(SGML) made it possible to render complex content on the other services (such as file servers or databases), the general
fly and link related information, even if it was distributed. approach to performing risk assessment and management is
Like with many other information systems technologies, very similar. One useful approach is described in the
the early implementation of the web included only very Special Publication (SP) series of the National Institute for
limited built-in security, especially since the system was Standards and Technologies (NIST) of the United States.
initially designed for use within a research facility. How- Specifically, SP 800-30 rev. 1 and SP 800-39 describe a
ever, the growth of the hypertext system at CERN into the comprehensive approach to ensuring threat and risk
World Wide Web (WWW) required much more advanced assessment and mitigation. The reader is strongly encour-
security controls. aged to review these documents for further guidance on
implementing their own risk management strategy.
Defining Threats to Your Web Assets
Initially, there were only very few real threats to the Surveying the Legal Landscape
WWW: early on, hackers proved their ability and
highlighted potential threats to the new environment by
and Privacy Issues
defacing web sites. Once commercial transactions (such as In addition to the embarrassment and potential liability for
online shopping) and other high-value information monetary damage to third parties after exposure to hackers,
exchanges were starting to use the web, the number of web operators are often also subject to other regulatory
potential threat actors and threats grew quickly. Today, any requirements. For example, web sites that store or process
public or private web application or service operator will personally identifiable information (PII) may be required to
need to perform at least a cursory threat and vulnerability disclose their data-handling policies, and may have to
assessment to determine appropriate risk mitigation strat- restrict access for young children. The legal requirements
egy for their web assets. for website operators vary from country to country, and
Depending on the use cases, the data, and the audience lack of clearly defined “borders” on the Internet may
of a web asset, a variety of threat actors should be require compliance with differing, sometimes contradicting
considered when performing a threat assessment. Among regulatory regimes.

Computer and Information Security Handbook. http://dx.doi.org/10.1016/B978-0-12-803843-7.00010-7 183

Copyright © 2017 Elsevier Inc. All rights reserved.
184 PART j I Overview of System and Network Security: A Comprehensive Introduction

Any web operator will minimally need to comply with create data) and DELETE (to delete data). In addition,
the terms of service of their service provider and the laws HTTP also supports other operations that allow compre-
applying to them. For example, US-based providers will hensive management of the service and the interaction.
need to review their web sites in the light of very diverse Roy Fielding formalized the common best practices
laws, including (but not limited to) the Children’s Online around creating HTTP services in his dissertation and
Privacy Protection Act (COPPA), Sarbanes-Oxley Act coined the term Representational State Transfer
(SOX), Health Insurance Portability and Accountability Act (REST) to describe the architectural style of well-
(HIPAA), and the Privacy Act. European operators will need designed HTTP systems.
to address not only the requirements of their respective local
The protocols, architecture, and design of web services
countries, but also the EU Data Protection Directive. In
alone are fairly complex. The reader is expected to have a
general, any website operator handling information from
basic understanding of how HTTP and SOAP work, how
their employees or customers, visitors, or third parties is well
they are currently being used, and how they can be created.
advised to consult with a local law firm that specializes in
The goals of this chapter are to provide a general overview
Internet, compliance, and privacy law.
of the breadth of web service security, provide an intro-
duction to the subject area, and guide the reader to sources
Web Services Overview with deeper information.
Web services have become a widely used technology in This chapter addresses both REST HTTP service and
both corporate and Internet applications. Information SOAP-based web services. Each technology has its
technology (IT) practitioners such as architects, de- strengths and weaknesses and users should clearly
velopers, and administrators have been moving away from enumerate the requirements they have for their web service
traditional client-server architectures to loosely coupled environment before deciding to implement one or the other.
service environments to a number of issues. Service ar- In many complex cases, a hybrid environment will prove to
chitectures rely on clearly defined interfaces so that ser- be the best approach (see Sidebar: “Protocol Versions”).
vice clients and service providers can change their internal
architectures independently from each other, allowing
decoupling of the development processes for different
Protocol Versions
systems components. This process started in the late 1980s
and has been implemented in specialized distributed ar- Within this chapter, we will always reference the latest
versions of the protocols referenced. Some of the protocols
chitectures such as CORBA, COMþ, or Java RMI. The
are backward compatible, since they only add features to the
success of web technologies in the mid-90s inspired sys-
overall specification, but in many instances the protocols
tem architects to profile these new platform-agnostic break backward compatibility to fix significant security
technologies to build distributed systems that can intero- holes. Existing implementations of these security protocols
perate across vendors and runtime architectures. Web sometime lag behind the latest standardized version
services have been defined in different ways; we will focus [Transport Layer Security (TLS) being one example], but
in this chapter on the following two principal realizations increasingly the standards community works in a much
of distributed services that typically use HTTP for more agile way, where implementation of draft specifica-
exchanging information: tions are available and fully supported by vendors (OAuth
2.0 or higher). Depending on the application of web ser-
l Simple Object Access Protocol (SOAP) web services vices, the user will need to make a business-requirements
have been popularized in the early 2000s by Microsoft and risk-based determination what version of the protocol
and IBM, and have seen broad adoption across very should be used.
different platforms. SOAP services are built around
the concept of a SOAP envelope, an XML document
that contains a SOAP header, and a SOAP body. The
header defines the necessary metadata for the SOAP 2. BASIC SECURITY FOR HTTP
message, including processing instructions and security
elements. The SOAP body candin principledtransport
APPLICATIONS AND SERVICES
any media type, although the core protocol was origi- Since HTTP services implementing a REST architectural
nally formulated around XML documents. style (often called “REST Services”) are simply using the
l HTTP services have been in use since the early days of HTTP stack, all security aspects of HTTP apply. At the same
the WWW. The original design of the HTTP protocol time, there is a critical distinction to web applications: for the
included not only the well-known operations such as latter, the user agent (the software making the HTTP requests)
GET (to retrieve data) or POST (to modify data) which is a web browser, which is event-driven and operated by a
are commonly used by web browsers, but also PUT (to human. As such operations such as providing username and
 Securing Web Applications, Services, and Servers Chapter | 10 185

password credentials, selecting Public Key Infrastructure mechanism (such as TLS) that provides for the confi-
(PKI) certificates, or making choices about how to interact dentiality of the channel.
with the web server are not complicated for the client. This is 2. Assigning username/password accounts to machines
all very different if the client user is an agent. tends to lead to bad code. Often, developers will hard-
Basic authentication and some other authentication and code the credential into the code, making changes
authorization mechanisms are built into the HTTP stack much harder. Even if a configuration file is used, the
and the layered protocols supported by most operating username and password are very often not cryptograph-
systems and clients. At the same time, many of these ically protected on disk.
security mechanisms were created to support end-user
Overall, it is not recommended to rely on username/
facing agents such as web browsers, and often require
password credentials (HTTP Basic Authentication) when
considerable human interaction in order to work as
implementing HTTP services, especially in production
designed. For example, HTTP Basic Authentication or
environments. Note that other browser-centric authentica-
HTML forms-based authentication with clear-text pass-
tion mechanisms (such as HTML forms-based authentica-
words works well for an end-user that needs to access a
tion) are not usable for client-server authentication in REST
website (or web application), but username/password to-
architectures.
kens are less ideal for machine-to-machine interactions,
since they (1) require a secure store of the secret, but (2) do
not offer a particularly high level of security. Transport Layer Security
This part of the chapter introduces a number of widely TLS3 is based on the Secure Socket Layer (SSL) protocol
available and deployed HTTP mechanisms that may be that was developed in the 1990s by the Netscape Corpo-
used to build interoperable, secure machine-to-machine ration. The basic design requires a X.503 V3 based PKI at
HTTP services. In general, most security mechanism sup- least for the server and requires client and server to main-
ported by the HTTP specification itself are typically the tain a session state. Both use PKI to negotiate a session
most interoperable, while layered protocols and mecha- master key: this approach ensures that the asymmetric
nisms (such as those provided by the GSS-API and SASL) cryptography is used to introduce client and server and
tend to be less interoperable out of the box. establish a secure channel between the two communication
partners. The establishment of the secure session key using
Basic Authentication symmetric cryptography allows leveraging the efficiency of
these mechanisms in bulk encryption transactions.
HTTP1 provides “Basic Authentication”2 as part of the
The SSL/TLS protocol stack (and also its most popular
standard HTTP stack, where the exchange of the credential
implementation, OpenSSL) have been subject to a large
is performed. For typical web applications, the server
number of significant vulnerabilities in recent years. These
denies access to the resources that was requested at the
were related to transport protocol implementation choices,
URI, and returns an HTTP status code of 401, including a
extension, cipher suite support, and other aspects of design
WWW-Authenticate header, which needs to be set to the
and implementation. The use of any version of SSL high at this
“Basic” authentication mechanism. The client then
time considered to be vulnerable to a number of different at-
responds with another request to the same resource, but
tacks and increasingly no longer supported by browsers, other
adds a WWW-Authorization header with the Base64
clients, and servers. While most clients and servers today still
encoding of the username and password. The server can
support TLS 1.0, it is recommended to move to TLS 1.2 to
then decode the username and password and verify the
avoid potential security holes. Also the use of strong ciphers is
credential. While this authentication mechanism is
becoming a new standard: new X.509 certificates are now
straightforward and very easy to implement, it is only of
issued with SHA-256 as the default signature algorithm, and
limited use in environments where HTTP is used for the
most certificates use Rivest, Shamir, and Adelman public/pri-
following machine-to-machine communication:
vate key pairs with 2048 bit or more for their key lengths. Also,
1. This mechanism transmits the username and password the use of elliptic curve cryptography (ECC) algorithms for
unencrypted. The simple Base64 encoding can be asymmetric cryptography is becoming more popular as well.
decoded by anyone and must be treated as clear text. In general, it is recommended to verify any TLS
As such, this authentication mechanism can only be configuration with an appropriate scanning tool. While
used in conjunction with a channel protection there any many commercial and free solutions available, a

1. RFC 2616, “Hyper Text Transfer ProtocoldHTTP 1.1”, R. Fielding

et al., Internet Engineering Task Force, June 1999.
2. RFC 2617, “HTTP Authentication: Basic and Digest Authentication”, 3. RFC 5246, “The Transport Layer Security (TLS) Protocol Version 1.2”,
J. Franks et al., Internet Engineering Task Force, June 1999. T. Dierks et al., Internet Engineering Task Force, August 2008.
186 PART j I Overview of System and Network Security: A Comprehensive Introduction

popular free web service for testing TLS setups can be DNS name itself by the subject identifier, thus
found at https://www.ssllabs.com/. providing additional protection against DNS attacks.
2. Channel protection. Once the secure channel handshake is
Server Authentication complete, the secure channel provides confidentiality to
the communication path between client and server. This al-
Every TLS transaction requires the server to authenticate
lows the exchanges of sensitive information including
itself to the client. This is typically initiated by the client
additional authentication and authorization data.
sending the server a list of supported TLS versions, sup-
3. REST client libraries can usually make use of operating
ported cipher-suites, and other connection information
(such as the time or random parameters). Note that this or runtime systems certificate stores in a very efficient
way. Certificate stores typically provide built-in protec-
initial request typically requires the client to connect to a
tions of the cryptographic material. Additionally, both
port different from the usual port for the protocol. For
client and server systems usually allow fairly simple up-
example, HTTP usually operates on TCP port 80, but the
dates of the certificates when needed.
TLS version of HTTP (called HTTPS) is defined to operate
4. TLS can provide a Message Authentication Code
on port 443. The server responds with a list including the
(MAC) for each packet, allowing full integrity protec-
same information and also the server PKI certificate. The
tion of the connection.
subject identifier of the certificate is typically the web
address of the server (such as https://www.example.com), The only significant drawback of using simple or client-
but there are other options such as wildcard certificates or authenticated TLS is the high cost for using a PKI: for
Subject Alternate Name (SAN) certificates as well.4 The cross-enterprise transactions, PKI certificates must be ob-
client can then use the server certificate to authenticate the tained through common trust anchors which may be too
server, and responds with a message that includes a master expensive in low-value transactions (such as social network
secret, which is used to generate the session keys. Once the interactions). For intraenterprise connections, a custom PKI
keys are available, the TLS handshake completes with the may be used, but the cost of maintaining this can also be
client and the server starting to use the session keys and substantial, especially for large enterprises.
shifting to an encrypted communication channel.

Mutual Authentication GSS-API Negotiated Security

Another way to perform authentication for HTTP-based
Mutual authentication means that both client and server are
service and application is through the use of the GSS-API
authenticated to each other, (the client needs to authenticate
and its security mechanisms. The GSS-API has been
to the server as well). This is achieved by the server sending
defined for C and the Java runtime,5 and provides a number
a Certificate Request message to the client as part of the
of standard features:
handshake. The client will then provide a user certificate to
the server. This establishes the identity of the client to the l Authentication of clienteserver relationship through a
server. While subject identifiers in client certificates can feature complete handshake protocol between client
vary, most often they are bound to the user’s email address. and server.
l Confidentiality and Integrity for the payload of the
Application to REST Services connection, independent of the protocols encapsulated.
This is achieved by wrapping the payload within the
TLS channel protection adds a number of security features to
structure needed for the GSS-API protected traffic.
the communication between a REST client and service, as
Note that the capabilities of this feature are strongly
follows:
dependent on the underlying security mechanism.
1. Server authentication using strong cryptographic l Extensibility and mechanism negotiation through the
methods. The server certificate is bound to the server’s SPNego pseudo mechanism. This is used by Microsoft
to integrate Kerberos with the HTTP protocol for authen-
tication and to provide a smooth browsing experience.
4. SAN certificates have a special multivalued extension (called sub- The preceding technology was initially developed in the
jectAlternateName) that permits the certificate to apply to multiple DNS early 1990s and has a high level of implementation
domain names. This can ber very useful for sites that can be reach with
different DNS names (such as multicountry sites), or it can be useful for
web servers hosting multiple different web sites. Wildcard certificates
apply to all hosts of a specific subdomain, such as *.example.com. This 5. The C binding is defined in the IETF RFC 2744 and the Java binding is
subject identifier will many any hostname under example.com. Note that standardized in JSR-72. See http://tools.ietf.org/html/rfc2744 and http://
there are no standardized ways of having multilevel wildcard certificates jcp.org/aboutJava/communityprocess/review/jsr072/index.html for more
such as *.*.example.com. information.
 Securing Web Applications, Services, and Servers Chapter | 10 187

maturity. At the same time, it very focused on traditional WS-Security Overview

clienteserver environments and encourages a much stron-
ger coupling of the participants than desired for typical web WS-Security7 (often abbreviated WSS) defines a Header
services. For example, when using Kerberos over SPNego extension to provide a number of features for SOAP-based
as the underlying security mechanism, the administrator messages, as follows:
will need to ensure that client and server are either part of l Signing the message to provide integrity protection and
the same Kerberos realm, or there is an established trust nonrepudiation;
relationship between the two realms. Since this trust and l Encrypting the message to provide message-level
deployment model does not scale to cross-organizational confidentiality;
deployments, this approach can only be used effectively l Attaching arbitrary security tokens to the messages to
within a single administrative domain. provide identity of the sender.
It should be noted that since WS-Security is only tied
3. BASIC SECURITY FOR SOAP SERVICES to the SOAP messaging structures, it is completely
transport independent and can therefore be used over the
The situation for SOAP-based web services (see Sidebar: SOAP HTTP binding, but also with any other form of
“SOAP-based Web Services”) is significantly different SOAP transport. At the same time due to its independence,
from basic HTTP services: while SOAP may use the HTTP WS-Security can be combined with the security mecha-
protocol for transport, it was designed to be transport in- nisms of the underlying transport security.
dependent, and as such needs to re-create the entire security To provide the various features mentioned in this sec-
stack in a self-contained way. This is achieved by extend- tion, WS-Security leverages the XML Encryption and
ing the SOAP headers to support security-related infor- Signature standards. Users of WS-Security should have a
mation in the WS-Security protocol, and other profiles and robust understanding of how these standards work, mini-
protocols that build on top of it. mally from an API perspective, but ideally also from a
protocol point of view. The WSS headers directly use
SOAP-Based Web Services the <Signature>, <KeyInfo>, and <EncryptedData>
SOAP version 1.26 or higher is a flexible XML-based proto- elements of the XML Signature and Encryption standards,
col to exchange information. Originally developed by respectively.
Microsoft, IBM, and others, SOAP is available today on most For example, a SOAP message may be signed and
web-enabled platforms. Conceptually, SOAP defines an encrypted at the message-level using WS-Security and
Envelope as the root node of the XML document. The En- transported over an encrypted HTTPS connection as
velope contains two child elements: the Header and the well. For complex situations, where the SOAP message
Body of the SOAP message. The Body typically contains the
is routed by SOAP intermediaries that sit between the
main payload of the message, which is intended to be an
sender and the server, this feature can be used to pro-
XML-serialized representation of a data model. The Header
section of the Envelope may contain metadata about the
vide both: (1) secure point-to-point connections between
message, sender, and receiver, and about the transaction the sender, receiver, and their respective intermediaries
itself. The Header is highly customizable and extensible. using HTTP over TLS, and (2) end-to-end security from
SOAP was originally developed as a web service proto- the sender to the receiver using message-level
col, with an HTTP transport binding. At the same time, the encryption.
designers of the protocol made sure that the SOAP specifi-
cation was not dependent on any features of the underlying
transport. As a result, SOAP can be used over a large number Protocol Design
of transport protocols today, thus providing a consistent way
of creating services over a number of different platforms. As discussed, WS-Security injects a security header as an
Such platforms include SMTP, FTP, and message queuing XML child node into the SOAP Header (see Fig. 10.1).
protocols. This flexibility does not come for free, though, This security header can contain a number of different
since many transport semantics (such as session security, elements that enable the various features of WSS. Note that
routing, acknowledgments, etc.) that are provided by the the following examples reference the usage of WS-Security
underlying transport protocols need to be replicated within with SOAP 1.2 or higher only. The WS-Security
the SOAP stack. This can lead to significant performance specification defines also the use of SOAP 1.1 or higher,
issues and replication of functionality at different layers.
but this will be omitted here. The namespace prefixes
For this chapter, it is assumed that the reader has a good
understanding of the basic SOAP protocol structures.

6. “SOAP Version 1.2”, M. Gudgin et al., W3C Recommendation, April 7. “Web Service Security: SOAP Messaging Framework 1.1”, A. Nadlin
2007.
et al., OASIS Open, November 2006.
188 PART j I Overview of System and Network Security: A Comprehensive Introduction

Signature is provided through the <ds:Signature>

element that may contain the crypto material (such as
a <ds:KeyInfo> element) and additional information to
provide identification of the type of signer, the signature,
and canonicalization8 algorithm, and references to the
signed elements.
For encryption of elements, WSS differentiates be-
tween header elements that need to be encrypted and the
main SOAP Body (or portions of the body). For the
headers, WSS introduces the <wsse:EncryptedHeader>
element that may be processed by SOAP intermediaries
or the final receiver of the messages. If the SOAP
handling system cannot decode the encrypted header it
needs to leave it in place. Within the SOAP body,
the <xenc:EncryptedData> element is used to wrap
encrypted parts of the XML infoset within the overall
message structure.
In either case, the WSS header will contain the
necessary key information to decrypt the data, similar to
how this is handled for signatures. When decrypting, the
decrypted elements replace the <xenc:EncryptedData>
FIGURE 10.1 Simple Object Access Protocol and WS-Security message and <wsse:EncryptedHeader> elements, respectively.
layout.

Usage of WS-Security
below are identical to the ones used in the WSS 1.1 or By itself, WS-Security is only of limited use: it describes
higher specification. For real implementations they may be how security elements such as tokens and signatures can be
different, as long as the XML namespace rules are incorporated into a SOAP message. It also provides limited
followed. instructions on how to protect portions of the message
The <wsse:Security> is the base WS-Security using these security elements.
header element within the <S12:Header> element of
the SOAP message. It may contain a number of typical
attributes from the SOAP headers, such as mustUnder-
stand, to indicate the receiver or intermediary must
Authentication With WS-Security
understand the WSS header in order to correctly process A common use of WS-Security is for authentication of
the SOAP message. Also, the <Security> header can be the incoming request. In order to process (an update to
extended with any additional attribute or child element, an account using a SOAP request), the bank service will
effectively providing a very flexible extension point. It need to verify the identity of the invoker (authentication)
should be noted that open-ended extension points like so that it can apply its authorization policies. For this,
thisdwhile desirable to protocol implementers and the clients will need to attach one or more security
vendorsdmay introduce significant interoperability is- tokens to the WS-Security header that prove their users’
sues when being deployed: if vendor-specific extensions identity. WS-Security provides for a number of built-in
are required for operation, environments that require tokens such as <wsse:UsernameToken> or the more
cross-platform interoperability may run into significant generic <wsse:BinarySecurityToken>, but it can also be
difficulties. extended to support other token types as well. Common
In order to enable signature and encryption of arbitrary stacks such as Apache Axis or .NET WCF support these
parts of the SOAP message, the WSS specification and others such as Security Assertion Markup Language
introduces the ability to reference nodes of the entire SOAP (SAML) or vendor-specific tokens as well (see Sidebar:
Envelope using the wsu:Id attribute. Similar to an anchor in “Attaching Policies to Web Services”).
an HTML page, an XML element within the message can
be tagged with this attribute and then be referenced within
the WSS header structures that are used for providing 8. WSS supports both W3C XML Canonicalization and W3C Exclusive
signature and encryption. XML Canonicalization. Since the later provides a better support for XML
namespaces, and is recommended in most situations.
 Securing Web Applications, Services, and Servers Chapter | 10 189

Example for a Web Service Definition

Attaching Policies to Web Services
Language for WS-Security
Authentication of a single request is achieved by providing
the token within the security header. Since there are The following Fig. 10.2 contains a sample WSDL9 for a
countless ways of doing this, the service needs to commu- very simple SOAP web service with a single operation. The
nicate to the client the type of acceptable tokens, acceptable service requires authentication using a SAML 2.0 or higher
configurations of these tokens, and how to protect them. This Security token using the SAML Token Profile version 1.1
is typically done by adding the WS-SecurityPolicy elements: or higher. Note that within this WSDL there is no directive
WS-SecurityPolicy is another OASIS Open standard, avail- how to utilize the information found within the SAML
able at http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
token for authorization. The SAML statement will contain
v1.3/os/ws-securitypolicy-1.3-spec-os.pdf. It can prescribe
information that is used for authentication and authoriza-
the required configuration for a number of WS-Security
related parameters. tion. How this is used by the application server runtime and
WS-Security Policy is written within the WS-Policy the service itself depends on the application server vendor
framework, which is for describing policies associated with and the service developer, respectively.
a web service. In order to make WS-Policy statements
available to clients, most stacks use WS-Policy Attachments,
4. IDENTITY MANAGEMENT AND WEB
a W3C Recommendation (available at http://www.w3.org/
TR/ws-policy-attach/) that describes how WS-Policy ele- SERVICES
ments map to Web Service Definition Language (WSDL) Electronic identities are routinely used to access logical and
elements.
physical resources, and have become a ubiquitous part of
our national infrastructure. Identity management systems
are responsible for the creation, use, and termination of
In the easiest case, a simple UsernameToken is used, electronic identities. However, Identity Management as a
which can include the password in clear text. Obviously, formal discipline is a fairly new concept.
such a token would typically not be used without protecting On the other hand, the advance of web services tech-
the message for confidentiality. Alternatively, a trusted nologies have far-reaching effects on the Internet and
authentication server could sign a UsernameToken or an enterprise networks. Web services technology can be
SAML statement. The service could then decide to trust the implemented in a wide variety of architectures, can coexist
authentication server, and not require additional credentials. with other technologies and software design approaches, and
If an SAML statement is used for authentication, the SAML can be adopted in an evolutionary manner without requiring
Token Profile for WS-Security will describe the possible major transformations to legacy applications and databases.
configurations that the server can request from the client. The security challenges presented by the web services
approach are formidable and unavoidable. Many of the
WS-I Security Profile features that make web services attractive, including greater
As seen earlier, the configuration parameters to simply accessibility of data, dynamic application-to-application
perform authentication can be very complex. While WS- connections, and relative autonomy (lack of human inter-
SecurityPolicy is capable to describe the requirements that vention) are at odds with traditional security models and
the server has, it is impossible even within a fairly rich controls.
policy framework to describe all possible parameters for the
WS-Security stack. Even though placement of individual
XML elements should not matter from an infoset perspec-
Background
tive, and most crypto parameters such as algorithms are Since web services are intended to implement a distributed
described in the core specification, tests between different architecture, it becomes very important to manage the
vendors have shown that acceptable interoperability cannot identities of the participating actors: different systems
be achieved without a very narrow profile. The WS-I orga- implementing the services or the clients need to fully
nization (now a subgroup of OASIS Open) created a number understand who they are interacting with in order to make
of such profiles. The WS-I Basic Security Profile includes access control decisions that are consistent with the
very detailed implementation guidance for WS-Security, security policies for the systems. While this has been
WS-SecurityPolicy, the various token profiles (username, always the case for complex systems, the loosely couple
SAML, X.509 certificate, Kerberos), and SOAP with At- design of web services exacerbates this problem and
tachments. While users of WS-Security are typically not requires a number of new patterns to address this in a
expected to implement these specifications and their profiles,
it is important to understand their relevance when creating
cross-platform services. 9. For readability, XML namespaces have been removed from the listing.
190 PART j I Overview of System and Network Security: A Comprehensive Introduction

FIGURE 10.2 Example Web Service Definition Language for WS-Security protected service.

reliable way. The identity management community created the operators of two separate identity servers (such as in
a number of patterns that allow not only simple Company A and Company B) decide to trust each
authentication, but also advanced patterns including: other’s authentication process. This is realized by allow-
ing a client to exchange a security token from the iden-
l Single Sign On (SSO) using mutually trusted identity
tity server of Company A with a security token from
servers. This idea is based on the SSO mechanisms
Company B. This allows the client to access services
used for web applications: a user (or machine entity)
that trust Company B’s identity server.
authenticates once to a trusted identity server, which is-
l Complex, distributed authorization. By fully decoupling
sues security tokens that can be used to sign into relying
the authentication process from the authorization to
parties (sometimes also called service providers). This
access a resource, web services can allow very flexible
pattern decouples the process of identification and
authorization mechanisms such as Attribute-Based
authentication itself from the use of the authentication
Access Control (ABAC).
and authorization.
l Federations of identity providers. In order to allow Other patterns, such as privacy preserving authentica-
cross-organizational access to web services, the concept tion and authorization have also been demonstrated
of an identity federation was introduced. In this pattern and implemented using web services-based identity
 Securing Web Applications, Services, and Servers Chapter | 10 191

management technologies. While many of these patterns which describe how the SAML protocol can be used with
were pioneered for the SOAP stack, recent developments the appropriate token types over different transport mech-
have brought most them to REST-styled HTTP services. anisms. The Bindings are then used to build profiles for
Due to its expressiveness and top-down design, SOAP- different SAML system participants such as web browser
based identity management is quite achievable. In real- SSO clients, identity providers, or attribute providers.
world implementations, some of the performance issues
of XML processing have limited the broad adoption of
Security Assertion Markup Language
SOAP-based identity management technologies. The
initially less feature-rich REST designs have always
Token Types
leveraged the efficiency of the underlying transport pro- The SAML tokens are supported by many different vendors
tocols, resulting in a much slower availability of useful and can be used with many different protocols, even those
patterns, but providing a much better price/performance that compete with the SAML request/response protocol.
ratio. The SAML 2.0 or higher specification identifies the
following three token types (called “Statements” in the
Security Assertion Markup Language specification):
The SAML10 was created to provide a means for l SAML Authentication Token. This statement describes
exchanging information about authenticated entities and how a user (or machine entity) authenticated to a given
their attributes between a client (also called service con- service. It can contain detailed information about the
sumer) and a service. Fundamentally, SAML defines a set authentication act, including the time, the subject, and
of security tokens that can hold information about an the authentication context.
entities’ authentication, their attributes, or their authoriza- l SAML Attribute Token. This statement can contain an
tion status.11 In addition, SAML defines a request/response arbitrary number of clear-text and encrypted attributes
protocol that allows exchanging SAML security tokens in about a given subject, as asserted by the identity pro-
remote procedure call (RPC)-style exchanges. vider. This statement is the foundation for many
The SAML protocol stack (see Fig. 10.3) extends from ABAC-based authorization schemes.
the basic tokens and protocol to include SAML Bindings, l SAML Authorization Decision Token. This statement
was deprecated by the eXtensible Access Control
Markup Language (XACML) protocol at the time of
publication of the SAML 2.0 or higher standard. It
has been kept within the specification text, but should
not be used unless for legacy interoperability purposes.
All tokens require a Subject element to identify the
principal of the assertion. This Subject can contain identi-
fiers (such as email addresses or distinguished names) and
SubjectConfirmation elements. The use of these fields is
specific to the protocols for which the tokens are used. For
example, the WS-Security SAML token profile12 defines
two common SubjectConfirmation methods: Holder-of-
Key (HOK) and Sender-Vouches.
HOK ensures that the sender of the SOAP message
has access to the private key of the Subject by requiring a
signature over parts of the message block. This
authenticates the subjects and confirms to the web service
the identity of the sender. In the Sender-Vouches method,
the web service trusts an authentication server to
FIGURE 10.3 Security Assertion Markup Language protocol stack. authenticate the client for them, and requires only a
signature by that authentication server over the message
10. SAML Technology Overview: N. Ragouzis et al., “Security Assertion block.
Markup Language (SAML) V2.0 Technical Overview”, OASIS Commit-
tee Draft, March 2008. SAML 2.0 Core: S. Cantor et al., “Assertions and
Protocols for the OASIS Security Assertion Markup Language (SAML)
V2.0” OASIS Standard, March 2005.
11. In SAML 2.0, the authorization token has been deprecated by the 12. R. Monzillo et al., “Web Service Security: SAML Token Profile 1.1”
XACML protocol. OASIS Standard, February 2006.
192 PART j I Overview of System and Network Security: A Comprehensive Introduction

Security Assertion Markup Language While the SAML protocol is standardized in the core
Protocol SAML specification it is not implemented by all vendors:
while SAML tokens have been popular across the entire
The SAML protocol (sometime called “SAML-P” to identity management landscape, early adopters of the WS-*
distinguish it from the SAML token format) is an XML- specifications such as IBM and Microsoft have been using
based protocol that implements a request/response pat- these tokens in with WS-Security, WS-Trust, and WS-
terns for exchanging information. It is completely transport Federation. Users will need to make sure what parts of
independent, and can therefore be used with a wide variety the SAML specification stack (tokens, protocol, bindings,
of system participants. The basic exchange implements a profiles) the vendors support.
Request message by a client that is answered by a
Response. The SAML protocol is self-contained and uses
its own mechanism to indicate response status, failures, and Using Security Assertion Markup Language
other interaction metadata. Similar to SOAP, this inde- Tokens With WS-*
pendence from the underlying transport results in less
SAML tokens have been used with other exchange pro-
effective architecture, since underlying functions such as
tocols as well. The term “WS-* stack” commonly refers to
status codes have to be replicated at the application level.
a set of protocols that build on top of the SOAP platform
There are a number of interactions defined in the basic
and enable additional functionality for SOAP-based web
SAML specification, as follows:
services. This includes features such as complex trans-
l SAML Assertion Query. This protocol is used to actions support (WS-AtomicTransactions), reliable delivery
request specific assertions in about subjects from an (WS-ReliableTransport), and service discovery (Universal
authoritative source. This can include authentication, Description, Discovery, and Integration, UDDI). Since
attribute, and authorization decision statements. The these are intended to be used in a transport-agnostic way,
response then includes a token for the requested infor- underlying features of message queuing systems cannot be
mation about the Subject. relied on for guaranteed delivery, but have to be created
l Authentication Request Protocol. An entity can use this within the SOAP envelope through SOAP header
protocol when it wishes to obtain a statement for estab- extensions.
lishing a security context for a principal. Typically, a For security, WS-Security defines the most fundamental
requester asks to obtain a SAML authentication asser- extension, and many of the other WS-* protocols imple-
tion from an Identity Provider (IdP) during a web ser- menting security functions rely on the WS-Security
vice invocation. framework. The use of SAML Tokens with WS-Security
l Artifact Resolution. A SAML Artifact is a reference to a is standardized in the SAML Token Profile 1.1 or higher.9
SAML statement instead of the statement itself. This
protocol is used to resolve a SAML Artifact into an WS-Trust Architecture
actual SAML assertion.
WS-Trust is an alternative to using some portions of the
l Single Logout. While SSO is very desirable from a user
SAML protocol for creating an environment with a mutu-
experience perspective, single logout is critical from a
ally trusted authentication server, a client, and a service.
security perspective. Within the SAML specification
WS-Trust uses WS-Security for wrapping security elements
stack, this protocol ensures that assertions can be
such as security tokens, signatures, and encrypted data
identified as invalidated once a logout was requested.
blocks.
It should be noted that this protocol does not guarantee
The mutually trusted entity is in the WS-Trust envi-
logout but requires the cooperation of all relying
ronment called a Secure Token Service (STS), which re-
parties.
sponds to token requests (see Fig. 10.4). At a high level,
l Name Identifier Management and Name Identifier Map-
the client (called a requestor) contacts the service (called a
ping. These protocols are used to create reliable, pseu-
relying party) and obtains through the WS-SecurityPolicy
donymous federations between IdPs in different
of the relying party service the token requirements. These
administrative domains.
requirements include the acceptable origin of the token
These protocols can then be used with different trans- (the STS (or list of STS) that are acceptable sources for
ports. The use of specific transport protocols with the SAML tokens).
protocol is called a “Binding” and specified in a separate The requestor then proceeds to request such a token
document. SOAP is one of the standards transports, but there from a STS by sending a RequestSecurityToken (RST)
are also other browser-centric transport bindings available, message to the STS service endpoint. This request will
as well. The Bindings are used to define “Profiles” which typically include appropriate forms of authentication (from
describe complex function systems such as IdPs. the requestor to the STS) by providing a security token
 Securing Web Applications, Services, and Servers Chapter | 10 193

FIGURE 10.4 WS-Trust architecture.

within the WS-Security headers of the WS-Trust RST requires a comprehensive PKI rollout, especially when
message. using user certificates for mutual authentication.
The STS builds a token to the specification of the Typical applications of HTTP applications and services
requestor and wraps this in the WS-Security header of in social networking or cloud environments have use cases
the RequestSecurityTokenResponse (RSTR) message. The that cannot be easily address with basic HTTP authentica-
requestor can then proceed to interact with the relying party tion schemes. Furthermore, the deployment of PKI in such
using the new token. environments is too expensive or extremely complex: PKI
implies a fairly high level of trust in the binding of the
credential to a system or the user, which is hard to control
Building Federations With WS-Federation
in highly dynamic environments.
Since WS-Trust is only used for building a distributed Based on these constraints a number of large web 2.0
authorization system, OASIS has created a number of other or higher providers (including Google, Twitter, AOL, and
protocols for the WS-* stack focusing on different func- others), as well as smaller companies with deep insight
tionalities. One of these is the WS-Federation specification into the architectures of dynamic web application and
which is used to enable the leveraging of security tokens REST-style HTTP services, started in 2004 developing
issued by STS form different administrative domains. This technologies that are complementary to the “heavyweight”
means that a client can obtain a token from “their” STS, and SOAP-centric identity management technologies. While
use this to access relying parties that usually trust only initially focused on simple data-sharing use case with
tokens issued by another STS. The prerequisite for this to limited risk (such as SSO for blog commenting), these
work is setting up a federation. technologies have matured to the point where they can be
It should be noted that the most significant amount of used to secure commercial services and provide a
work for creating a federation is typically not the technical simplified experience for users of social media and other
configuration: creating and maintaining the necessary web applications.
business agreement between two organizations is complex
and requires collaboration with legal, finance, and poten-
OAuth Overview and Use Cases
tially human resources subject matter experts.
The OAuth protocol dates back to the early days of social
networking sites. The standard use case is for safely sharing
Advanced HTTP Security
user data held at one site with another site. This would occur
The basic security functions of HTTP described earlier are when site A is a photo-hosting site and site B is a site that
sufficient for simple clienteserver systems, but are hard to makes prints from photos (see Fig. 10.5). In this use case,
manage for complex multiparty interactions. In addition, users have an account at both sites and store their photos at
the most common security transportdTLSdtypically site A. For creating a new set of prints, users will not upload
194 PART j I Overview of System and Network Security: A Comprehensive Introduction

FIGURE 10.5 OAuth basic use case.

or transfer their photos to site B, but instead authorize site B from the draft versions to the completed version are
to access their photo stream (or a portion thereof) on site A. minor, if any.
This is effectively achieved by initially logging into site B
and indicating the location of their photo stream (through a
OpenID Connect
dropdown menu) at site A. When site B now tries to access
the photo stream, the users are redirected to the login screen The original OpenID protocol was built on the concept of
for site A where they need to provide their credentials. Once using URLs as identifiers for users (a user would use
logged in site A will create a token that site B can use for something like “https://example.com/user” for their user-
accessing the users’ photo stream and attach this token to the name). This was intended to solve the problem of discovery
HTTP redirect back to site B. The end state is now that site B in identity management: any dynamic interaction between a
has a token that it can use at attach to the HTTP request user and a service would only be able to leverage identity
when obtaining the photos. management protocols, if the relying party and the identity
The exchange is somewhat more complicated than in provider had an existing relationship. For well-defined
the illustration, since the Printer service initially obtains an cross-organizational interactions this is quite achievable,
unauthorized request token in the initial exchange between but requires to configure the respective IdPs (or STSs),
the Printer and the Photo Host service. The request token is relying parties, and requestors to use the acceptable ser-
then authorized by the user and provided to the Printer vices for identity management and authorization services.
which exchanges it into an access token. The goal for this While the OpenID protocol did solve this problem with
use case is to keep the accounts at the two services separate the URL identifier, users typically did not accept this
while still allowing authorized information sharing between scheme, so the large web 2.0 or higher providers such as
the two sites. Google, Twitter, Facebook, AOL, etc. solved this by
OAuth 2.0 or higher is at the time of writing completed creating specialized buttons to use for OpenID login. Since
with regards to standardization at the Internet Engineering most sites desired to support at least the big social
Task Force (IETF). The final protocol is now available. networks and identity providers, the login sites often
Most implementations already support OAuth 2.0 or featured more than five specialized login button, leading to
higher; and, updates to implementations for transitioning the term “NASCAR problem”: similar to racing cars in
 Securing Web Applications, Services, and Servers Chapter | 10 195

NASCAR, login sites would be littered with banners from it shared some architectural similarities. In fact, the
all major login providers. XACML replaces the SAML 2.0 or higher authorization
Additionally, the initial versions of OpenID had a decision statement with its own request response
number of significant security issues, leading to the reali- protocol.
zation that it would be helpful to design a new version of
OpenID that could leverage a secure HTTP-based identity
eXtensible Access Control Markup
transport protocol. The natural choice was OAuth, and
OpenID Connect now uses OAuth as its underlying secu-
Language Overview
rity protocol. Simplified, OpenID Connect creates an Within the XACML model, there are a number of actors
identity provider web service and uses OAuth to protect that enable the distributed authorization environment. Note
access from relying parties to it. that some of these actors can be co-located: certain appli-
ances or access managers allow configurations where PEP,
5. AUTHORIZATION PATTERNS PDP, and PAP are co-located, as discussed in the following
In addition to the authentication mechanism (such as a pass- components:
word), access control is concerned with how authorization l Access requester (or client). This is the entity that initi-
patterns are structured. In some cases, authorization patterns ates a request.
may mirror the structure of the organization, while in others it l Policy Enforcement Point (PEP). The PEP intercepts the
may be based on the sensitivity level of various documents and request from the client to the resources and performs an
the clearance level of the user accessing those documents. authorization check. This actor is sometimes integrated
with a reverse proxy (a façade service that wraps the
Access Control Models resource and replicates the resource’s interface to the
clients).
Early systems implemented fairly simple access control
l Policy Decision Point (PDP). The PDP performs the
models that rely mostly on the identity of the user and
actual policy evaluation, based on the information in
define access control lists (ACLs) that are stored with the
resource that is subject to that access control list. This the request from the PEP, a policy set (the merged set
of applicable policies, based on a policy merging sys-
model has sometimes been called “Identity Based Access
tems), configured attribute sources, and other environ-
Control” (IBAC) and has proven to be very efficient and
mental factors (such as time of day, origin or
easy to implement. Most modern operating systems
destination of request, etc.).
support IBAC based access control for file systems access
l Policy Administration Point (PAP). The policy admin-
and other security related functions. While fast for small
istration point allows the configuration and administra-
ACLs, very large ACLs are inefficient to evaluate, and the
tion of applicable access control policies. The PDP is
need to store the ACL (which is effectively a security
policy for the resource) decentralized with the resources configured through the PAP to use a specific set of
policies.
can cause significant lifecycle management problems.
l Policy Information Point (PIP). The PIP provides
Some solutions such as user groups or ACL inheritance
contextual information input into the policies, based
have been implemented to mitigate these shortcomings,
on a request from the PDP. If the PIP provides specific
but overall the limitations of IBAC limit its use for
attributes for identities, e.g., in the form of a Directory
large-scale applications. Other access control models
Server, the PIP is sometime also called an Attribute
include Role-Based Access Control (RBAC)13 and
Source (AS).
ABAC. Core to these models is a better separation of
resources and applicable access control policies. l Resource. The resource itself provides the service for
the client. While XACML is typically used for
Web services have been pioneering technologies for
SOAP services, there is no requirement for the
implementing ABAC models especially through the
resource to be implemented as a SOAP service. For
introduction of the eXtensible Access Control Markup
example, a combined PEP/service façade can be used
Language (XACML).14 Since XACML was developed to
to expose the functionality of a legacy application to
complement SAML with a flexible authorization system,
SOAP-enabled clients.
These preceding components and how they related to
13. The U.S. National Institute of Standards and Technology (NIST) has each other are shown in Fig. 10.6. Conceptually, the
published a number of documents on RBAC and how it can be imple-
Requester tries to access the Resource (typically a SOAP-
mented. See http://csrc.nist.gov/groups/SNS/rbac/ for more information.
14. XACML is standardized at OASIS Open in the XACML Technical based web service, but this is not a requirement within
Committee. See here: https://www.oasis-open.org/committees/tc_home. XACML) and is intercepted by the PEP. The PEP itself
php?wg_abbrev¼xacml.
196 PART j I Overview of System and Network Security: A Comprehensive Introduction

6. SECURITY CONSIDERATIONS
Security considerations are essential to implementing and
integrating a comprehensive strategy for managing risk for
all IT assets in an organization. This should result in more
cost-effective, risk-appropriate security control identifica-
tion, development, and testing.

Avoiding Common Errors

FIGURE 10.6 eXtensible Access Control Markup Language actors The flexibility of web-based systems and the ease of
overview. implementing new services lead to an early proliferation of
web applications and web services. It became obvious
pretty quickly that these new technologies resulted in a
formulates a decision request to the PDP with the infor- number of mistakes that were independently made
mation that is available to it, namely metadata from the by many developers. Security research groups and
request and the resource. organizations started to look into this problem and
With the PDP, the applicable access policies are iden- identified a number of antipatterns and mistakes that were
tified, evaluated, anddif necessarydcombined into a sin- particularly common, and identified measure to counter
gle policy decision. Note that XACML defines a rich policy them. The following gives an overview of two commonly
language for describing access control policies in terms of referred to lists of common mistakes and useful controls,
Targets, Rules, and Constraints. respectively.
The PDP responds to the PEP in a Result Response with
one of the following four possible decisions: Permit, Deny,
Indeterminate (no decision was possible, based on the Open Web Application Security Project
available policies and information), or NotApplicable (the (OWASP) Top 10
request was not applicable in this context). The response
may include additional obligations that need to be abided The Open Web Application Security Project (OWASP)
by. The complete XACML protocol, policy language, Top 10 list15 was developed by the OWASP community to
result definition, and combination algorithms can be used enumerate common problems with web applications. This
for very complex situations, and it is beyond the scope of list focuses specifically on web application risks, and deals
this chapter to describe the details of the XACML protocol. with both transport issues (HTTP) as well as content
problems (HTML) and how content is rendered within
XACML and SAML for ABAC and RBAC browsers. The latter issues are less interesting for
developers of web services, since the user agent is typically
The core XACML protocol architecture is modeled around not a browser, and the data may be represented as HTML,
the concepts of ABAC: attributes (either provided by an AS but most often is not. It is updated occasionally to reflect
or other PIPs providing environmental attributes) are the changing security environment.
evaluated in the context of a specific request. While most Fig. 10.7 shows the 2013 version of the OWASP Top
situations will require the identity of the requestor, ABAC 10. Out of this list only A3, A4, A6, A7, A8, and A9 are
can even allow pseudonymous access to resource, as long highly relevant to web service developers. Since REST-style
as the PDP can obtain sufficient information to arrive at a HTTP service leverage the features of HTTP more heavily
“permit” authorization decision. than SOAP service using the HTTP transport binding, the
The core set of XACML specifications also includes former will likely have to pay more attention to avoiding
guidance on how an RBAC model can be implemented mistakes identified in the list. At the same time, SOAP
using XACML. The basic idea is to model role membership services operating within standard runtime environment can
through a multivalued attribute. This attribute is then suffer from issues such as security misconfigurations (A6)
evaluated in the context of access control policies designed or problems with the transport layer protection (A9) just as
to reflect the role-based approach.
At the same time, the technology used to implement the
access control model should not be confused with the
access control model itself. This means that while XACML 15. The document is available from https://www.owasp.org/. The last
is currently the predominant technology to implement update to the list was done in 2013. At the time of this writing, OWASP is
ABAC in distributed systems, they should not be equated. requesting input to the 2016 list, which is scheduled to be released during
the second half of 2016.
 Securing Web Applications, Services, and Servers Chapter | 10 197

Center for Internet Security Top 20

Critical Security Controls
The Center for Internet Security (CIS) Top 20 list of critical
security controls16 enumerates the most important technical
and administrative controls to prevent or limit attacks on
computer systems. The list was developed by a number of
experts from the US government and the commercial sector
and condenses a lot of best practices of good systems
management. They provide not only a description of
FIGURE 10.7 Open Web Application Security Project Top 10 (2010).
implementable countermeasures and system configurations,
but include also metrics to measure the effectiveness of the
controls within a given environment. Additionally, the CIS
Top 20 control description include references to the NIST
easily. In the following, the more pertinent elements form SP 800-5317 control set, which is mandatory for many
the OWASP top 10 are briefly discussed: systems operated by the US federal government.
l A1: Injection flaws, such as SQL, OS, and LDAP The controls themselves are generic and not specific to
injection may occur when untrusted data is sent to a web services. At the same time, they can be applied to the
web service trying to exploit the underlying business architectural concepts, technologies, and deployed systems
logic. implementing web services. The complete list is an
l A2: Broken Authentication and Session Management. If excellent starting point for any secure system design, but
access to the HTTP resources where the service is host we will focus here on the most applicable controls for
is not protected properly, arbitrary users may invoke the securing web service deployments.
service and cause confidentiality and integrity problems.
Authentication issues can arise when the verification of Critical Control 3: Secure Configurations
accounts with the user database is compromised, user for Hardware and Software on Laptops,
information is leaked through other channels, or the
authentication session parameters are not set properly.
Workstations, and Servers
l A4: Insecure Direct Object References. If input of the ac- This control requires a secure configuration of all system
cess URL (for REST-style services) or the content of the components. This can be implemented by creating standard
SOAP request is not verified through input validation system images that are hardened against attacks. Such
techniques, a malicious user may replace legitimate hardening may include disabling nonessential system ser-
data references with improper data. For example, if a ser- vices, limiting the visibility to network probes, configuring
vice call should reference Alice’s account for receiving a kernel-level security enforcement rules, etc. A secure
money transfer, a malicious attacker could try to replace baseline operating system limits the potential damage that a
Alice’s account number with Eve’s, thus redirecting the misconfigured or compromised web service or client can
transfer to a wrong account. cause.
l A5: Security Misconfiguration. This can include default
account, unpatched or unmaintained server code, refer-
ences to old versions of services, etc. Any security mis- Critical Control 4: Continuous
configuration can be exploited by attackers to gain Vulnerability Assessment and Remediation
access, elevate privileges, or violate confidentiality or
integrity of the data. The window for attacking weak systems is significantly
l A6: Sensitive Data Exposure. Web services can easily reduced by continuously monitoring and assessing the
expose sensitive data including authentication informa- vulnerability profile of all deployed systems. With a
tion, PII, financial, or health data. comprehensive program in placedthat should ideally
l A8: Using Components with Known Vulnerabilities. consist of automated and human componentsdpotential
Web services rely on a large stack of third-party soft-
ware, including the operating system, format parsers,
virtual machines, web servers, application servers, cryp- 16. The list is available at http://www.sans.org/critical-security-controls/d
It was formerly know as the SANS Top 20 Critical Security Controls, but
tographic libraries, and many other tools. Any known
transitioned with version 6.0 to the Center for Internet Security.
vulnerability in this third-party code may lead to a 17. NIST Special Publication (SP) 800-53 (in it current version R4) is a
compromise of the entire service. comprehensive list of information security controls and they verification
procedures.
198 PART j I Overview of System and Network Security: A Comprehensive Introduction

weaknesses in the web service application runtime or the many IT architects, developers, and administrators have a
implementing code itself can be detected and fixed in near hard time staying on top of their field both from an
real time. This minimizes the attack window for threat application and security perspective. Security training
actors significantly. and evaluations should be part of everyone’s re-
sponsibility. Exploring the usefulness of relevant security
certifications for key staff members may augment this.
Critical Control 9: Limitation and Control Overall, only senior-level management sponsorship can
of Network Ports, Protocols, and Services ensure the successful implementation of this control.

It is crucial to have a comprehensive list of allowed port,

protocols, and system services for all active and passive Critical Control 18: Application Software
network devices. Each individual component must only be
Security
allowed to perform its designated function and use the
appropriate set of network resources to do so. This way In the context of the SANS Top 20, this control focuses on
compromised devices can be identified much more easily: the security of the code implementing the service itself.
if a server designated to provide web service over HTTPS While there are other frameworks available as well, the
suddenly starts to send out Border Gateway Protocol OWASP Top 10 list (see Fig. 10.7) is a good starting point
(BGP) messages, network monitors and intrusion detec- for assessing the security of the service and client software
tion and prevention systems can react immediately and quality.
take that system off the network to prevent unauthorized
routing of data.
Critical Control 20: Penetration Tests
and Red Team Exercises
Critical Control 11: Secure Configurations Even the best security engineering teams will make mis-
for Network Devices Such as Firewalls, takes or miss possible attack vectors when protecting
Routers, and Switches critical resources such as web services. Only a compre-
Not only the actual business systems such as servers and hensive penetration test and recurring exercises can expose
client, but also the supporting network infrastructure com- potential security flaws. More details on creating a test
ponents need to be configured in the most secure way. This program for web services are explained later in the
control is complementary to Critical Control 3, and should chapter.
be implemented equivalently.

Other Resources
Critical Control 12: Boundary Defense There are many other, often industry specific sets of
Firewalls and other boundary defense technologies have security controls that can handle web service security.
been available for a long time, and despite them having a Examples include the American Institute of Certified
bad reputation for preventing advanced attacks, they are Public Accountants (AICPA) Service Organization
very useful in preventing certain classes of vulnerabilities. Controls (SOC) 2: “Controls at a Service Organizations
A solid boundary defense also enables close monitoring of Relevant to Security, Availability, Processing Integrity,
data ingress and egress, and allows to inspect and control Confidentiality, or Privacy,”18 which specify requirements
information flow from the web service to the client and vice for cloud providers and can have relevance in the context
versa. Separating the rest of the world from the internal of operating web service on behalf of customers. Another
networks also make monitoring of the use of ports, pro- set of applicable security controls includes the NIST SP
tocols, and service (Critical Control 9) much easier. 800-53 controls,19 which include SOA controls in their
latest revision.
There are other resources that address SOA-specific
Critical Control 17: Security Skills issues as well. One example is the Common Attack
Assessment and Appropriate Training to
Fill Gaps 18. See http://www.aicpa.org/soc for more information on the SOC
reports.
All personnel involved in the creation and maintenance 19. All NIST SPs can be found at http://csrc.nist.gov/publications/
of the web service must be qualified to perform their job PubsSPs.html.
functions. While this seems like an ancient IT adage,
 Securing Web Applications, Services, and Servers Chapter | 10 199

Pattern Enumeration and Classification (CAPEC)20 that determining the problems with the exposed service, from a
features a catalog of techniques used by attackers to number of different angles.
break into systems. While this database is intended to
cover all typical attack vectors against systems, it has a Vulnerability Assessment Versus Penetration Testing
specialization for service-oriented issues. The informa-
In the past, Vulnerability Assessment and Penetration Testing
tion within the database is typically fairly comprehensive
have sometimes been used synonymously. While their goals
and addresses not only specific attack methodologies, but and sometimes the techniques are similar, there is a funda-
defines also a framework for classifying these mental difference between the two:
approaches. l Vulnerability Assessments are cooperative engagements,
Fig. 10.8 provides a sample CAPEC pattern that applies where the security expert, the developers, and the ad-
to SOA, in this case on WSDL scanning. It provides a fairly ministrators are working hand in hand to understand,
comprehensive set of attributes of this particular attack, and document, and eliminate vulnerabilities of the exposed
suggests possible mitigation strategies to counter this attack services. The assessors should have full access to the
pattern. To use this catalog efficiently, it is recommended source code, the interface definition (such as the WSDL
that one search the site on specific technologies and for SOAP services), security documentation, and privi-
leged access to the servers hosting the services. The end
develop a list of countermeasures for mitigation.
goal is a plan to improve the security posture of the
deployed service.
Testing and Vulnerability Assessment l Penetration Tests, on the other hand, are noncooperative
Testing Strategy exercises, where the owners of the web service are not
necessarily aware of the fact that a penetration test is
As identified in the CIS Top 20 list of Critical Controls and underway. Depending on the rules of engagement, the
many other documentations of security best practices, penetration testers (sometime called “red team”) may use
testing and continuous monitoring are central to maintain- a large variety of techniques to gain access or subvert a
ing a secure environment. While tests during the design of a deployed service, including trying to get physical access
software package such as a service are standard develop- to the hosting servers. Furthermore, the red team may
operate under rules that allow them to permanently
ment practices,21 the deployed service itself should be
damage the deployed service in order to better under-
evaluated in context as well.
stand the potential security impact a real attack may have.
Such tests can include simple functional tests that verify While penetration test often result is more in-depth
the invocation of a service call in the deployed environment analysis the security posture, most companies will not
(or a mockup of that environment), but they may also allow the red team to perform a full-scale attack on pro-
include performance tests to ensure that the service behaves duction systems.
correctly under heavy load. There are a number of com-
mercial and open source tools available for performing
such test, including the popular soapUI framework22 or To perform a comprehensive vulnerability assess-
webInject23 open source projects. ment of a service installation, the analyst should be
familiar with the base techniques of vulnerability as-
Vulnerability Assessment Tools sessments for servers. There are many tools available
for performing such an assessment, both commercial as
In addition to functional testing at development and deploy well as open source-based solutions. Specialized Linux
time web services should undergo at least a vulnerability distributions such as Kali Linux24 are specifically
assessment to determine their actual vulnerabilities (see designed for vulnerability assessments and testing,
Sidebar: “Vulnerability Assessment Versus Penetration and have many of the best tools preinstalled. For
Testing”). Such a vulnerability assessment is focused on HTTP-based systems, testers should minimally employ
w3af, MetaSploit, openVAS, and Nessus in addition to
other standard tools.
20. The CAPEC catalog can be found at http://capec.mitre.org/.
Finally, let’s take a brief look at the web applications,
21. This may include Unit testing, continuous builds, and other functional services, and servers challenges that still need to be
tests to verify the correct functioning of the service. For services, Unit tests addressed. The following checklist (see checklist: “An
may include not only API invocations of the implementing classes, but Agenda for Action for Security Actions That Web Appli-
also explicit calls to the service interfaces exposed on the network. Note cations, Services, and Servers Need to Consider”) discusses
that configuring such tests with services that implement security func-
tionality directly (e.g., in-code authorization) may be very complex and not
several web applications, services, and servers security
necessarily feasible.
22. See http://www.soapui.org/ for information on using soapUI.
23. WebInject is available form http://www.webinject.org/. 24. See http://www.kali.org/ for more information on Kali Linux.
200 PART j I Overview of System and Network Security: A Comprehensive Introduction

FIGURE 10.8 Sample Common Attack Pattern Enumeration and Classification for Web Service Definition Language scanning.
 Securing Web Applications, Services, and Servers Chapter | 10 201

challenges in detail, including web services discovery, challenges that have yet to be addressed. Some examples of
quality of service, quality of protection, and protection from these challenges are:
denial of service attacks.
l Repudiation of transactions;
7. CHALLENGES l Secure issuance of credentials;
l Exploitation of covert channels;
While many of the web applications, services, and server l Compromised services;
challenges have been met with existing standards, there are l Spread of malware, such as viruses and Trojan horses
a number of challenges that standards organizations are via SOAP messages;
addressingdparticularly in the area of web services dis- l Denial of service attacks;
covery and reliability. The Web Services Interoperability l Incorrect service implementations.
Organization (WS-I) acknowledges that there are many

An Agenda for Action for Security Actions That Web Applications, Services, and Servers Need to Consider
The items in this section are possible actions that organizations servers can be implemented to withstand a variety of
should consider; some of the items may not apply to all or- attacks.
ganizations. In particular, it is necessary to balance these ac- _____4. Use Performance Analysis and Simulation Tech-
tions against budget requirements and the potential risks an niques for End-to-End Quality of Service (QoS) and
organization’s Web applications, services, and servers may Quality of Protection. Queuing networks and simu-
face (check all tasks completed): lation techniques have long played critical roles in
_____1. Replicate Data and Services to Improve Availability. designing, developing, and managing complex in-
Since web applications, services, and servers are formation systems. Similar techniques can be used for
susceptible to denial-of-service (DoS) attacks, it is quality assured and highly available web applica-
important to replicate data and applications in a tions, services, and servers. In addition to QoS of a
robust manner. Replication and redundancy can single service, end-to-end QoS is critical for most
ensure access to critical data in the event of a fault. It composite services. For example, enterprise systems
will also enable the system to react in a coordinated with several business partners must complete busi-
way to deal with disruptions. ness processes in a timely manner to meet real-time
_____2. Use Logging of Transactions to Improve Non- market conditions. The dynamic and compositional
repudiation and Accountability. Nonrepudiation and nature of web applications, services, and servers
accountability require logging mechanisms involved makes end-to-end QoS management a major chal-
in the entire Web applications, services, and server lenge for service-oriented distributed systems.
transaction. In particular, the level of logging pro- _____5. Digitally Sign UDDI Entries to Verify the Author of
vided by various UDDI registries, identity providers, Registered Entries. UDDI registries openly provide
and individual web services varies greatly. Where the details about the purpose of a web service as well as
provided information is not sufficient to maintain how to access it. Web applications, services, and
accountability and nonrepudiation, it may be neces- servers use UDDI registries to discover and dynami-
sary to introduce additional software or services into cally bind to web applications, services, and servers
the SOA to support these security requirements. at run time. Should an attacker compromise a UDDI
_____3. Use Threat Modeling and Secure Software Design entry, it would be possible for requesters to bind to a
Techniques to Protect from Attacks. The objective of malicious provider. Therefore, it is important to digi-
secure software design techniques is to ensure that tally sign UDDI entries so as to verify the publisher of
the design and implementation of web applications, these entries.
services, and server software does not contain defects _____6. Enhance Existing Security Mechanisms and Infra-
that can be exploited. Threat modeling and risk structure. Web applications, services, and servers
analysis techniques should be used to protect the web rely on many existing Internet protocols and often
services application from attacks. Used effectively, coexist with other network applications on an orga-
threat modeling can find security strengths and nization’s network. As such, many web applications,
weaknesses, discover vulnerabilities, and provide services, and server security standards, tools, and
feedback into the security life cycle of the applica- techniques require that traditional security mecha-
tion. Software security testing should include nisms, such as firewalls, intrusion detection systems
security-oriented code reviews and penetration (IDS), and secured operating systems, are in effect
testing. By using threat modeling and secure software before implementation or deployment of web ser-
design techniques, web applications, services, and vices applications.
202 PART j I Overview of System and Network Security: A Comprehensive Introduction

8. SUMMARY be used over the SOAP HTTP binding, but also with
any other form of SOAP transport.
The practices recommended in this chapter are designed to 4. True or False? Since web services are intended to
help mitigate the risks associated with web applications, implement a distributed architecture, it becomes very
services, and servers. Web applications, services, and important to manage the identities of the participating
servers are important drivers for the software industry. actors: different systems implementing the services or
The primary goal of service-oriented computing is the clients need to fully understand who they are inter-
to make a collection of software services accessible acting with in order to make access control decisions
via standardized protocols whose functionality can be that are consistent with the security policies for the
automatically discovered and integrated into applications. systems.
While several standards bodies (such as W3C and OASIS) 5. True or False? Most modern operating systems support
are laying the foundation for web applications, services, IBAC-based access control for file systems access and
and servers, several research problems must be solved to other security related functions.
make secure web applications, services, and servers a re-
ality. Service description, automatic service discovery as Multiple Choice
well as QoS are some of the important problems that need 1. SOAP services are built around the concept of a:
to be solved. A. SOAP header
Web applications, services, and servers are increasingly B. SOAP body
becoming an integral part of organizational IT infra- C. SOAP envelope
structuresdeven though there are still unmet security chal- D. SOAP message
lenges. To this end, the development and deployment of secure E. All of the above
web applications, services, and servers are essential to many 2. The simple Base64 encoding can be decoded by anyone
organizations’ IT infrastructures. However, web applications, and must be treated as:
services, and servers security standards do not provide all A. Bad code
of the required properties to develop robust, secure, and B. Clear text
reliable web applications, services, and servers. To C. Basic authentication
adequately support the needs of the web applications, D. Server authentication
services, and servers based applications, effective risk E. All of the above
management and appropriate deployment of alternate 3. What can usually make use of operating or runtime sys-
countermeasures are essential. Defense-in-depth through tems certificate stores in a very efficient way?
security engineering, secure software development, and A. TLS
risk management can provide much of the robustness and B. PKI
reliability required by these applications. C. MAC
Finally, let’s move on to the real interactive part of this D. REST client libraries
Chapter: review questions/exercises, hands-on projects, E. Two
case projects, and optional team case project. The answers 4. WS-Security25 (often abbreviated WSS) defines a
and/or solutions by chapter can be found in Appendix K. Header extension to provide a number of features for
SOAP-based messages, except which two?
CHAPTER REVIEW QUESTIONS/ A. Signing the message to provide integrity protection
EXERCISES and nonrepudiation.
B. WS-Security can be combined with the security
True/False
mechanisms of the underlying transport security.
1. True or False? The development of a distributed hyper- C. Encrypting the message to provide message-level
text system in the early 1990s at the CERN in confidentiality.
Switzerland was one of the defining moments in making D. Attaching arbitrary security tokens to the messages
the Internet available to an audience beyond academia to provide identity of the sender.
and specialized communities. E. WS-Security leverages the XML Encryption and
2. True or False? Since HTTP services implementing a Signature standards.
REST architectural style (often called “REST Ser- 5. The identity management community created a number
vices”) are simply using the HTTP stack, all security as- of patterns that allow not only simple authentication,
pects of HTTP apply.
3. True or False? It should be noted that since WS-
Security is only tied to the SOAP messaging structures, 25. “Web Service Security: SOAP Messaging Framework 1.1”, A. Nadlin
it is completely transport independent and can therefore et al., OASIS Open, November 2006.
 Securing Web Applications, Services, and Servers Chapter | 10 203

but also advanced patterns including the following, SOAP messages can be viewed or modified by attackers as
except which two? the messages traverse the Internet. What options are
A. Other patterns, such as privacy preserving authenti- available for securing web service messages?
cation and authorization.
B. Single Sign On (SSO) using mutually trusted iden-
tity servers. Optional Team Case Project
C. Federations of identity providers.
D. SAML Authentication Token. Problem
E. Complex, distributed authorization. Security decisions must always be made with an under-
standing of the threats facing the system to be secured.
EXERCISE While there are a wealth of security standards and tech-
Problem nologies available for securing Web services, they may not
be adequate or necessary for a particular organization or an
When multiple requesters, providers, and intermediaries are individual service. For that reason, it is important to un-
participating in a web service transaction, it may be derstand the threats that face web services so that organi-
necessary to coordinate them. What are the two different zations can determine which threats their web services must
types of mechanisms for coordinating web services? be secured against. What are the top threats facing web
services today?
Hands-On Projects
Project
Because a web service relies on some of the same under-
RESOURCES
lying HTTP and web-based architecture as common web [1] The opinions and guidance presented here are those of the author and
applications, it is susceptible to similar threats and vul- do not necessarily reflect the positions of The MITRE Corporation,
nerabilities. Web services security is based on what several its customers or sponsors, or any part of the U.S. Federal
important concepts? Government.
[2] The document is available from https://www.owasp.org/. The last
update to the list was done in 2010.
Case Projects [3] The list is available at http://www.sans.org/critical-security-controls/.
[4] NIST Special Publication (SP) 800-53 is a comprehensive list of in-
Problem
formation security controls and they verification procedures.
Web services rely on the Internet for communication. [5] See http://www.backtrack-linux.org/ for more information on
Because SOAP was not designed with security in mind, BackTrack.