Security Laboratory

Security Laboratory

Security Laboratory: Cryptography in Business Series

We are grouping papers in this series to focus on the many facets of data encryption.

Other Related Articles in Security Laboratory: Cryptography in Business Series

Secure Web Services

By Stephen Northcutt
secure web services

"Organizations are adopting SOA (Service-oriented Architecture) to support their mission critical applications. SOA is a computing paradigm emphasizing dynamic service discovery, composition, and interoperability. According to Wikipedia, Service Oriented Architecture (SOA) is an evolution of distributed computing and modular programming. SOAs build applications out of software services. Services are relatively large, intrinsically unassociated units of functionality, which have no calls to each other embedded in them. They typically implement functionalities most humans would recognize as a service, such as filling out an online application for an account, viewing an online bank statement, or placing an online book or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.Web services are a technology that can be used to implement SOA and are increasingly becoming the SOA implementation of choice."[1]

The National Institute of Standards and Technology special publication 800-95 Secure Web Services is one of the best publications they have ever produced. It helps us understand the growth in both numbers and importance of web applications and how vulnerable they are. As they say themselves, "The advance of Web services technologies promises to have far-reaching effects on the Internet and enterprise networks. Web services based on the eXtensible Markup Language (XML), SOAP, and related open standards, and deployed in Service Oriented Architectures (SOA) allow data and applications to interact without human intervention through dynamic and ad hoc connections. Web services technology can be implemented in a wide variety of architectures, can co-exist with other technologies and software design approaches, and can be adopted in an evolutionary manner without requiring major transformations to legacy applications and databases."

SP 800-95 gives solid architectural guidance, it is a break through document, but the content is beyond the reach of most managers. When we read terms like SOA, SOAP, TLS, XML, XACML, UDDI, WSDL our eyes glaze over even though we know this is really important material. This short document will help break it down for you step by step. SANS also offers a course on the subject, by the end of the class you will understand secure web services and will be ready to ask your web team the right questions and give the right guidance. There are no prerequisites, some basic IT and IT Security previous knowledge is assumed. However, this document serves as a read ahead material for students. If you do not have an IT background that is familiar with enterprise web applications, we highly recommend you read this document before attending.[2]

The Foundation is XML

The Extensible Markup Language (XML) is a general-purpose markup language. It is classified as an extensible language because it allows its users to define their own tags. Its primary purpose is to facilitate the sharing of structured data across different information systems, particularly via the Internet. It is used both to encode documents and serialize data.[3] Here is an example:

<?xml version="1.0"?>
<burns>Say <quote>goodnight</quote>, Gracie.</burns>
<allen><quote>Goodnight, Gracie.</quote></allen>
</oldjoke> [4]

SOAP Simple Object Access Protocol

SOAP is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework that more abstract layers can build on.[5] So, SOAP (Simple Object Access Protocol) is a means of implementing webservices across the Internet:

One can send data (a message) over the Internet to another (third party) server. This server parses the request and sends the result (response) back to the originating server. The responding server may modify the incoming data, it may also just deliver any content as requested. SOAP can either be sent in a synchronous way when it e.g. contains an RPC-call, or in an asynchronous way when it contains an XML-message. The latter is usually the case. SOAP does not care about the content, only about the addressee. You might as well regard it as a simple envelope: it can carry anything, it is not concerned about the content. Just let the mailman (usually HTTP) deliver the envelope.[6] Here is an example of a SOAP envelope, there are additional required elements, but this is enough to recognize SOAP:

<?xml version="1.0"?>

In most Web services, there are two types of SOAP (Simple Object Access Protocol) messages: requests and responses. When a SOAP request is received, the Web service performs an action based on the request and returns a SOAP response. In many implementations, SOAP requests are similar to function calls with SOAP responses returning the results of the function call.

Notional SOAP Example
Let's say I am setting up a webserver that provides answers to mathematical questions. Somebody surfs to my site and asks: "What is the square-root of 2349870942423?". What happens:
Via UDDI my server finds out how can it provide the answer: "Ah, is one of the servers that knows how to handle this".

  1. Then via WDSL my server finds out how to approach this server: OK, I just have to send the following string: sqrt 2349870942423.
  2. My server takes a SOAP-envelope, inserts this string, and sends it away.
  3. The math-server replies, which enables me to show the answer on my site.

What is UDDI and WDSL?

UDDI (Universal Description Discovery and Integration) registries openly provide details about the purpose of a Web service as well as how to access it. In particular, UDDI provides Models as "a way to mark a description with information that designates how it behaves, what conventions it follows, and what specifications or standards the service complies with." Attackers may use this information to find potential flaws in the Web service. For example, the UDDI entry may show that the Web service uses a vulnerable specification. Any information in excess of that required to bind to the Web service may benefit an attacker.

Additionally, Web services use UDDI registries to discover and dynamically bind to Web services at run time. Because the UDDI specifications did not address digitally signing entries until version 3.0.2 (released as an OASIS standard in 2005), many UDDI registries do not provide a robust mechanism for verifying the authenticity of registry entries. This may allow malicious Web services to be added to the registry and used by other Web services. Ideally, you should upgrade to version 3 of UDDI. "The Version 3 specification acknowledges and enables UDDI to be employed in a variety of different milieux. Because of the diverse set of environments for different UDDI registry implementations – internet, extranet, intranet, development, test, production, etc. – there is a need to provide flexibility for implementations to support vastly different operational policies. With this in mind, significant work was undertaken to identify all the policy decisions that each UDDI registry and/or node must make. Using the policy guide that is now part of the Version 3 specification, different UDDI implementations can mold a particular registry given its context."[8]

To define the format of each SOAP (Simple Object Access Protocol) message, W3C developed the Web Service Definition Language (WSDL). WSDL interfaces are created by each Web service and can be shared to allow dynamic binding. Through dynamic binding, Web services can communicate with newly added services without any additional programming or configuration changes. To facilitate the discovery of Web services, a discovery standard called UDDI (Universal Description, Discovery and Integration) was developed. UDDI allows Web services to search for one another dynamically. When combined with WSDL, Web services can easily discover and use new services at run-time without human intervention.

XACML for authorization
Authorizations for Web services are often done through custom implementations, but the XACML (Extensible Access Control Markup Language) is an OASIS standard available for performing authorization decisions, eliminating the time and cost associated with developing and testing a custom solution. "XACML provides a policy language which allows administrators to define the access control requirements for their application resources. The language and schema support include data types, functions, and combining logic which allow complex (or simple) rules to be defined. XACML also includes an access decision language used to represent the runtime request for a resource. When a policy is located which protects a resource, functions compare attributes in the request against attributes contained in the policy rules ultimately yielding a permit or deny decision."[9]

Transport Layer Security to Protect the Data in Transit

The Secure Sockets Layer (SSL) protocol, now generally defined by the TLS standard, was developed by Netscape Communications in 1994 to provide application-independent secure communications over the Internet. SSL procedures are most commonly employed on the Web with the Hypertext Transfer Protocol (HTTP) for e-commerce transactions, although SSL is not limited to HTTP. SSL uses cryptography to provide message privacy, message integrity, and client and server authentication, and operates on TCP port 443. "Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).

TLS is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. The TLS Record Protocol provides connection security with some encryption method such as the Data Encryption Standard (DES). The TLS Record Protocol can also be used without encryption. The TLS Handshake Protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before data is exchanged. "[10]

SSL and TLS provide for:
  • Key Establishment
  • Confidentiality with Triple DES-EDE-CBC (and other protocols considered less secure) and TLS supports AES
  • Signature (RSA, DSA) and TLS is considering Elliptic Curve with a draft internet standard
  • Hash MD5, SHA-1[11]

Putting it all together
We describe our message with XML stored in a SOAP envelope, we use WSDL to define services and UDDI as a directory to those services, we can authorize with XACML and protect the data in transit with TLS. SOAP offers and exposes more business logic than a regular webserver. Focus on perimeter security is no longer enough. SOAP, along with .NET- and Web Sphere based architectures, requires a different approach to Internet Security. Architectural questions rise, like:

1. Which functionality should be confined to the DMZ?
2. Which application-level risks are we exposed to?
3. How can we maintain central control, while security measurements are implemented within the application, at different levels within the organization?
4. Should we add additional gateways to terminate traffic from the Internet?[6]

As managers, we need to understand enough about Service Oriented Architecture to guide our technical people in balancing the needs of the business and technology and security. We need to answer the question, "How can we, cost effectively, implement sufficient application security while maintaining good performance?" If you have already signed up for the course, Secure Web Services for Managers, we will see you in class!

General note: Document is heavily based on National Institute of Standards and Technology special publication 800-95 Secure Web Services additional references are:
6. Michel Ludolph (paper sent by email)