Malicious content attacks, meanwhile, try to force a SOAP endpoint (server) to do something it wasn't meant to do--such as retrieve data it's not authorized to access, or even destroy data through SQL Injection and manipulate content within a SOAP message. The result: The receiving endpoint consumes excessive resources and crashes or becomes unresponsive.

Operational attacks produce a denial of service. Like malicious content attacks, they typically manipulate the XML message or the schema to tie up server resources.

Token Security

Several standards address application-layer security, which extends to Web services and SOAP:

» XML-Encryption provides full- or partial-message encryption.

» XML-Digital Signatures let a sender cryptographically sign messages, which can then be used as authentication credentials or a way to check data integrity.

» XML-Schema can be used to define an XML message's appearance. It also can guard against some content-based attacks, such as buffer overflow and SQL/XQuery Injection.

Your Input Requested We're always working to improve site content, but we need your help. Please take a few minutes to answer our short survey about our Newsletters.

Both XML-Encryption and XML-Digital Signatures allow for partial message signing and encryption, letting you use SOAP intermediaries, such as management, logging or routing nodes. Because transport-layer security makes intermediate processing difficult if not impossible, you need these standards to protect data within a SOAP message.

WSS, recently ratified by OASIS (Organization for the Advancement of Structured Information Standards), combines several standards for securing SOAP messages. WSS defines two profiles that address authentication and authorization: the UsernameToken Profile and X.509 Certificate Profile. Each provides the same information: an identity that is verifiable by an edge security device or by the application.

Username Token Element in the WSS Header Click to Enlarge

The UsernameToken specifies a method for passing a user name along with a security token. The security token is often a password, but it doesn't have to be (even though the tags within the element use the term password). The password can be clear text--in which case the Type value of the Password node is PasswordText--or a hash, indicated by the type PasswordDigest (see "UsernameToken Element in the WSS Header").

The Nonce node is useful for detecting replay attacks and it's Base64-encoded, unless otherwise specified. The Created node is a time stamp showing when the UsernameToken was created.

WSS helps determine whether access to a service is permitted, and it verifies the identity of the requesting user. Web services security gateways from Check Point Software Technologies, DataPower, Forum Systems, Reactivity and Westbridge Technologies all support WSS, as do Web services management products from Actional, Digital Evolution, Infravio and Oblix.

But Web services management products don't protect against malicious attacks. Most provide basic schema validation and sometimes data-scrubbing (see our review of these products in this issue). So it's up to the security gateways, sitting at the edge of the network, to prevent malicious attacks.