I am Vipul Patel; was associated with Information Security Research Lab (ISRL) while doing masters (Computer Science – Information Security) with the Department of Computer Engineering at National Institute of Technology, Karnataka from 2008-2010 during which the work elucidated in this article was carried out. You can reach me @ vip04pat[at]gmail[dot]com
The basic mechanism to communicate with SOAP based Web Services is XML messages which are processed by the server. Data is extracted from this XML message and converted to language specific data types which your Web Services understand. Malformed XML messages may have devastating effect on the server. Smartly manipulated SOAP messages get through the business logic and result in inconsistent execution of business logic with altered service parameters. It may also bring down the server resulting in denial of service attack. Aforementioned scenarios become possible when SOAP messages are not validated properly. Ideally, we rely on default validation mechanism provided by the web service engine which however is not always effective due to the fact that XML schema files used for validation are ill defined. Often, various Web Service standards such as WS-Security, WS-Routing etc. are employed/revoked to meet changing business requirements. Such changes significantly alter structure of the SOAP messages. Hence, it becomes essential to amend schemas used for validation to reflect these changes in SOAP message structure. However, handcrafting schema files is cumbersome and it’s very likely that minute schema details may skip through which may then pave way for malign messages. Hence, we need a mechanism to generate schemas in line with changing business requirements.
This tool operates on the SOAP messages logged by a SOAP message validator in the format suitable for processing. This tool starts by converting each SOAP message from XML to XSD form. It’s very likely that multiple SOAP messages appearing distinct in XML form due to different node values would result in the identical XSD. Hence, we compute XSD tree signature to skip processing the same schema repeatedly. Obtained XSD is then normalized for the purpose of comparison. Having obtained normalized XSD trees, each of this XSD is compared for equivalence against reference XSD which is the schema currently being used for validation which needs to be updated. Set of XSD are bucketed based on the measure of similarity with the reference schema. Now, each of these obtained buckets is processed in succession. The set of XSD available in bucket are checked for equivalence. Based on the measure of similarity, two XSD are merged if they are found to be similar. Resultant XSD inherits properties of both XSD. If equivalence test determines that two XSD differ by large extent then they are not merged and they become part of different buckets. This way comparison continues until no more merging is possible. Finally, all deduced XSD after merging represent different class of messages encountered by the Web Services. Subset of these XSD may represent legitimate SOAP messages while remaining XSD represent instance of attack vectors. Reference XSD is then modified in line with XSD representing legitimate requests.
This video will help you understand steps to be followed to run this tool: http://www.youtube.com/watch?v=sEjyi_XFrZA
Visit this URL for more information: http://isea.nitk.ac.in/currproj/08IS09F/
You can download source from here: http://isea.nitk.ac.in/currproj/08IS09F/licence.php