An XML Signature includes a "Reference" element pointing to the signed data. The parsing application must "dereference" (i.e. pull down) the reference URI. The XML Signature standard states that: "XML signature applications MUST be able to parse URI syntax. We RECOMMEND they be able to dereference URIs in the HTTP scheme." [RFC3075 - XML-Signature Syntax and Processing ]. However, this introduces a vulnerability, if the referenced data is bogus, or simply a way to waste recipient system resources pulling down a large file.
REST, Web 2.0 and SOA
Although SOA was originally associated with the triumvirate of SOAP, WSDL, and UDDI, many developers preferred to use more lightweight REST services which are closer to how browsers interact with Websites. The Web 2.0 movement contributed to this, because Rich Internet Applications (RIAs), make use of REST services to pull data from Web servers to the browser. The technology which enables Web 2.0 includes JavaScript on the browser side, for the most part calling REST Web Services at the server side. For example, the Flickr website includes JavaScript which runs in the browser which calls a server-side Web Service to rename a photo. In "AJAX" (Asynchronous JavaScript and XML), the client-side JavaScript calls back to Web Services on the server in order to pull down XML or JSON (JavaScript Object Notation) data. This happens asynchronously, without the user being required to browse to a new Web page (hence the A in AJAX is "Asynchronous").
In the Web 2.0 world, it is the back-end Web Services which become a key point of attack. This is sometimes termed the "large attack surface" of Web 2.0. An attacker can try to attack an application through its client interface, or they can simply bypass the interface and simply go straight after the back-end Web Services instead.
Wait: Is this a solved problem?
At this point, some readers may be thinking "this is not all that different from traditional Web applications, so why is it secured differently?" After all, in Web 2.0, Web browsers are used, Web Servers are used, and a user is involved. Indeed, when data is being sent between a Web Browser and a Web Server, it does make sense to scan the data for evidence of attempts to perform attacks like SQL Injection or cross-site scripting. Also, when XML is on the network, it does make sense to scan it for attacks such as XML Denial of Service or XPath Injection. In addition, secure coding practices still apply here. Rich applications on browsers present enhanced secure coding responsibilities. Cross-site scripting (CSS) is a possibility if an attacker is able to insert JavaScript into the data sent down to the browser to be rendered. Since many Web 2.0 "mash-up" scenarios depend on JavaScript being served down to the client, the possibility of malicious JavaScript slipping through occurs. This must also be detected and blocked.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.