The other side of the moon

Web service calls from a web page to a back end service can easily be made using XHR as long as the service runs on the same domain that the page is served from. For cross-domain requests, however, we have a problem. Typical methods of doing cross-domain requests require script nodes, a server side proxy, a flash based transport, or submitting a hidden form to an iframe target.

While the server side proxy and flash based transport both add an external dependency the script node can only make a GET request, and the hidden form approach can only send URL encoded key/value pairs... that's until we try a bit of trickery.

<form id="soap" method="POST" action="[SOAP entry point URL]" enctype="text/plain">
<textarea name="<?xml version">
"1.0" encoding="UTF-8"?>
[SOAP message here]
</textarea>
</form>

<script>
document.getElementById("soap").submit();
</script>

And that's it. The key elements are highlighted. In particular, you set the form's enctype attribute to text/plain. This makes sure that none of the data is URL encoded. Then a clever trick that works well with XML documents. Set the text field's name to <?xml version, ie, the starting text of an XML document. Omit the = sign and set the value to everything else.

When the form is submitted, the browser sends form fields as key=value, one on each line (that's how text/plain works). In this case, it sends the following:

<?xml version="1.0" encoding="UTF-8"?>
[SOAP message here]

Which essentially submits the SOAP payload to the web service.

Caveats

Naturally, all browsers don't work alike. For this particular example, all Webkit based browsers are broken. They don't handle an enctype of text/plain correctly. Chrome, Safari and Konqueror all set the Content-type header to text/plain, but the actual submitted data is URL encoded. This is consistent with research done by Gregory Fleischer and Bug #20795 filed on WebKit. Firefox (as far as Netscape 4 IIRC, probably earlier), IE (6 and above) and Opera handle it correctly.

C-Surfing on SOAP

There are security concerns with this approach as well, and in my opinion they are bigger than any benefit this might bring. An attacker can use this method to CSRF your SOAP based web services. Given this, it's a good idea to make sure that all your web service calls also have some kind of nonce or token that can only be generated if the request originated from your site.