SOAP Faults - Too much information

I gave a presentation at the RSA Conference back in April about "Case Notes from a Vulnerability Assessment of a Bank's Web Services". A thread running through the presentation was that SOAP Faults present "Too Much Information". Every time we sent an XML message which broke the bank's Web Services, we would get a SOAP Fault message which included information that is helpful for an attacker. For example, one message showed a Hibernate stack trace, indicating to us that Hibernate was being used. Another message, prompted by an External Entity attack, gave us back information about the local file system path. Check out the presentation for all the information (anonymized though, so you don't know the identity of the bank, which is still in business :-) ).

Most users of the Vordel XML Gateway know that you can assign a SOAP Fault as a fault handler, and customize what goes back to the client in the SOAP Fault. Also, most users know that you can create a reusable sub-policy which is called by another policy (like a subroutine in a programming language, and, indeed, like a reusable Web Service). But did you know you can combine the two capabilities? You can create a reusable policy and assign it as the fault handler.

In the example below, I have dragged in a "Policy Shortcut" onto the canvas. I right-click on it and say "Set as Fault Handler". So, if the XML Gateway finds any problem with the XML message, or with the back-end Web Service, then it runs this sub-policy. The sub-policy I'm using ships as standard in the "Policy Library", and it simply returns a HTTP 403 "Forbidden" message to the client. This gives no information to the client about why exactly their message was blocked. As part of that sub-policy, you could also send a notification to an administrator, return back a cached response from the Web Service, strip out part of the message which is harmful, quarantine the message, or redirect the request to a back-up Web Service.