Web services and security are two of the hottest topics in IT today. Therefore, it is hardly surprising that web services security is the focus of intense work in standards bodies and the labs of security vendors.
The early work on XML and web services security focussed on the aspects of security which are sometimes abbreviated to ‘CIA’: Confidentiality, Integrity and Availability. Confidentiality and integrity can be satisfied using cryptography. With XML, the XML Encryption and XML Signature standards provide, respectively, confidentiality and integrity for XML documents.
The WS-Security standard, which was only ratified by standards body OASIS in April 2004, describes how these two XML security standards apply to SOAP messages. SOAP is central to web services. It lays down a set of rules for how two applications should communicate together.
Availability is a basic security requirement which is often overlooked. However, denial-of-service attacks are an issue for XML and web services because of the high processor load when parsing XML documents.
Much of the recent work on web services security standards has focussed on identity and access control, commonly known as ‘AAA’ security — Authentication, Authorisation and Audit. This reflects the fact that web services are finding applications in partner-integration projects, situations that in the past would have involved a costly leased-line or subscription to an electronic data interchange (EDI) network.
Trusted connections
Although the term ‘web services’ implies ‘services on the web’ that are publicly available to anyone with a web browser, such public services are the exception. Web services are being used by insurers to connect to brokerages, for example, and by global manufacturing companies to link together their regional operations.
In both cases, the chief security requirement is to ensure that only trusted customers, partners and suppliers can connect. WS-Security is also relevant; in particular, the WS-Security X.509 Token profile and the WS-Security UsernameToken profile may be used to embed credentials into SOAP messages sent to a web service for authentication.
These credentials may then be used to perform AAA security. A security assertion mark-up language (SAML) standard token may be issued in order to assert that the client was authenticated, was authorised or has a certain attribute, such as a credit limit.
The Web Services Interoperability (WS-I) body takes the standards from OASIS and the Worldwide Web Consortium (W3C), as well as examining current practice by vendors and customers, to produce usage ‘profiles’.
These profiles describe how the standards are to be used together to achieve common tasks. The WS-I released a draft Basic Security Profile earlier this year. This draft includes profiles for SSL and HTTP-Authentication, alongside profiles that use WS-Security.
Finally, content-filtering also needs to be considered to protect against potential buffer overflow and SQL injection attacks.
Wily attackers may also intercept a valid XML message that contains a valid security token for AAA security and then ‘replay’ it – the equivalent of finding a signed document beside a fax machine and re-sending it.
If the recipient is not careful about examining timestamps or numbering in the messages they receive, then they may trust this second, bogus message. WS-I describes best practice with regard to time stamps and message numbering, since this is a vague area in the standards themselves.
Finally, SOAP messages may contain attachments, and these may be threatening if they are very large and difficult to process, or if they harbour viruses.
