Web Service Security Basics | HACKING EXPOSED WEB APPLICATIONS, 3rd Edition

Feeling a bit nervous about publishing that shiny new web service outside the company firewall? You should be. This section will discuss some steps you can take to protect your online assets when implementing web services using basic security due diligence and web servicesspecific technologies.

Web Services Security Measures

Due to the relative newness of the technology, web services security continues to evolve . As of this writing, it entails implementing classic web application security best practices, while keeping an eye on developing security standards like WS-Security. We'll discuss both of these approaches in this section.

Authentication

If you implement a web service over HTTP, access to the service can be limited in exactly the same ways as web applications, using standard HTTP authentication techniques discussed in Chapter 4, such as Basic, Digest, Windows Integrated, and SSL client-side certificates. Custom authentication mechanisms are also feasible , for example, by passing authentication credentials in SOAP header or body elements. Since web services publish business logic to the periphery of the organization, authentication of all connections to the service is something that should be strongly considered . Most of the models for web services contemplate business-to-business applications, not business-to-consumer, so it should be easier to restrict access to a well-defined constellation of at least semi-trusted users. Even so, attacks against all the basic HTTP authentication techniques are discussed in Chapter 4, so don't get too overconfident.

SSL

Because of their reliance on XML, which is usually cleartext, web services technologies like SOAP, WSDL, and UDDI are uniquely exposed to eavesdropping and tampering while in transit across the network. This is not a new problem and has been overcome using Secure Sockets Layer (SSL), which is discussed in Chapter 1. We strongly recommend SSL be used in conjunction with web services to protect against no-brainer eavesdropping and tampering attacks.

XML Security

Since web services are built largely on XML, many standards are being developed for providing basic security infrastructures to support its use. Here is a brief overview of these developing technologieslinks to more information about each can be found in the "References and Further Reading" section at the end of this chapter.

XML Signature A specification for describing digital signatures using XML, providing authentication, message integrity, and nonrepudiation for XML documents or portions thereof.
Security Assertion Markup Language (SAML) Format for sharing authentication and authorization information.
Extensible Access Control Markup Language (XACML) An XML format for information access policies.

We're generally not very impressed with buzzwords and acronyms, especially when they're unproven. Furthermore, we've never actually run across implementations of these technologies in production environments, so have not had an opportunity to test them in the real world. Our mention of these budding XML security standards here is not meant to imply competence or reliability, but rather to raise awareness.

WS-Security

On April 11, 2002, Microsoft Corp., IBM Corp., and VeriSign Inc. announced the publication of a new web services security specification called the Web Services Security Language, or WS-Security (see links to the specification in the "References and Further Reading" section at the end of this chapter). WS-Security subsumes and expands upon the ideas expressed in similar specifications previously proposed by IBM and Microsoft (namely, SOAP-Security, WS-Security, and WS-License).

In essence, WS-Security defines a set of extensions to SOAP that can be used to implement authentication, integrity, and confidentiality in web services communications. More specifically , WS-Security describes a standard format for embedding digital signatures, encrypted data, and security tokens (including binary elements like X.509 certificates and Kerberos tickets) within SOAP messages. WS-Security heavily leverages the previously mentioned XML security specifications, XML Signature and XML Encryption, and is meant to be a building block for a slew of other specs that will address related aspects of security, including WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, and WS-Authorization.

The best way to describe WS-Security is via an example. The following SOAP message contains the new WS-Security header and an encrypted payload (we've added line numbers to the left column to ease description of individual message functions):

 (001) <?xml version="1.0" encoding="utf-8"?> (002) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"             xmlns:ds="http://www.w3.org/2000/09/xmldsig#"             xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"             xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> (003)   <S:Header> (004)      <m:path xmlns:m="http://schemas.xmlsoap.org/rp/"> (005)         <m:action>http://stocktrader.edu/getQuote</m:action> (006)         <m:to>http://stocktrader.edu/stocks</m:to> (007)         <m:from>mailto:bob@stocktrader.edu</m:from> (008)         <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id> (009)      </m:path> (010)      <wsse:Security> (011)         [additional headers here for authentication, etc. as required] (012)         <xenc:EncryptedKey> (013)             <xenc:EncryptionMethod Algorithm=                         "http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> (014)             <ds:KeyInfo> (015)               <ds:KeyName>CN=Alice, C=US</ds:KeyName> (016)             </ds:KeyInfo> (017)             <xenc:CipherData> (018)                <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0... (019)                </xenc:CipherValue> (020)             </xenc:CipherData> (021)             <xenc:ReferenceList> (022)                 <xenc:DataReference URI="#enc1"/> (023)             </xenc:ReferenceList> (024)         </xenc:EncryptedKey> (025)         [additional headers here for signature, etc. as required] (026)      </wsse:Security> (027)   </S:Header> (028)   <S:Body> (029)      <xenc:EncryptedData                  Type="http://www.w3.org/2001/04/xmlenc#Element"                  Id="enc1"> (030)         <xenc:EncryptionMethod               Algorithm="http://www.w3.org/2001/04/xmlenc#3des-cbc"/> (031)         <xenc:CipherData> (032)            <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0... (033)            </xenc:CipherValue> (034)         </xenc:CipherData> (035)      </xenc:EncryptedData> (036)   </S:Body> (037) </S:Envelope>

Let's examine some of the elements of this SOAP message to see how WS-Security provides security. On line 3, we see the beginning of the SOAP header, followed on line 10 by the new WS-Security header, wsse:Security, which delimits the WS-Security information in the SOAP header. As we note in line 11, there can be several WS-Security headers included within a SOAP message, describing authentication tokens, cryptographic keys, and so on. In our particular example, we've shown the xenc:EncryptedKey header describing an encryption key used to encrypt a portion of the SOAP message payload (line 12). Note that the encryption key itself is encrypted using the public key of the message recipient ("Alice" in line 15) using RSA asymmetric cryptography, and the encrypted payload element is referenced on line 22 as "enc1." Further down in the body of the SOAP message, on line 29, we can see the data encrypted with the key using 3DES (note the Id="enc1"). In summary,

Header line 18: 3DES symmetric encryption key (encrypted using recipient's public key)
Body line 32: 3DES encrypted data payload

Alice can receive this message, decrypt the 3DES key using her private key, and then use the 3DES key to decrypt the data. Ignoring authentication and key distribution issues, we have achieved strong confidentiality for the payload of this SOAP message.

As we write this, WS-Security is still evolving. But it is clearly built to leverage several established, secure messaging architectures, including asymmetric key cryptography, and it obviously has the backing of web technology heavyweights like IBM and Microsoft. We've already talked to a few enterprise web development houses that are looking with great anticipation to using WS-Security for securing interapplication communication of all kindskeep your eye on developments in this sphere.