SOA Architecture & SOAP Protocol Architecture Detail & Attack Vector


Published on

SOA Architecture & SOAP Protocol Architecture Detail & Attack Vector by Nabarun sengupta @ null Pune Meet, November, 2010

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • DOM based parsers load the entire XML stream into the memory creating a hierarchical object that is referenced within the app logic. Obvious attack vector is inputting large XML files to consume server-side resources during parsing, resulting in DOS attack.
    SAX based parsers are not susceptible to the Denial of Service attacks. Because SAX based parsers are event driven, they parse the XML stream as needed, thus holding a maximum of 2 elements in memory at given time. They are susceptible to XML injection
  • SOA Architecture & SOAP Protocol Architecture Detail & Attack Vector

    1. 1. Penetration testing using open source tools
    2. 2. Agenda  What is SOA and SOAP communication?  What are web services?  Attacker’s approach Google Hacking Universal Description Discovery and Integration (UDDI)  Exploiting XML parsers  Error Handling  Attack simulation Technique & Tools  Simulating the attack  Conclusion
    3. 3. What is SOA? SOA is similar to building blocks. Conventionally, the components of an IT industry were tightly rigid, so implementing change was difficult. With SOA it is easy to assemble, easily reconfigurable.
    4. 4. How SOAP communicates?
    5. 5. What is the meaning of web service? Web service is a server- oriented system which operates on server side, and performs tasks, when it is called upon by an application. Web service is registered in a web service registry, which an application uses to call specific service it requires. A web service is not language and platform dependent, it uses XML to communicate with other services or application.
    6. 6. Web service in Action The communication starts with the user submitting the data. 1. The application contacts the UDDI to look up the service required to perform this functionality. UDDI ProviderClient The UDDI provider creates a binding which associates the message to the service requested, and its location. The UDDI provider then returns a WSDL file to the client, which the application completes as a SOAP message.
    7. 7. Web service in Action The Soap message then gets sent to the application server which hosts the web service needed to execute the current operation. This is done by binding the details in the WSDL file from the UDDI.
    8. 8. Web service in Action Using the SOAP instructions, the web services can correctly execute the task according to the parameters it was given, and deliver the processed conversation. Note: Appending ?wsdl or .wsdl reveals the wsdl file.
    9. 9. Attacker’s approach  Google hacking Filetype: wsdl Indexof “wsdl” Inurl: wsdl Inurl: asmx (note that asmx is the WSDL equivalent in  UDDI (Universal Description and Integration): This provides a centralized repository of web services and their wsdl files. Service providers often post their details using public UDDI’s to discover at run time.
    10. 10. Web Application v/s Web services WEB APPLICATION WEB SERVICES 1. XSS 2. SQL Injection 3. Malicious File execution 4. Broken Authentication and Session Management 5. Insecure Direct Object References 6. Cross-Site Request Forgery (CSRF) 7. Insecure Cryptographic Storage 8. Failure to Restrict URL Access And many more….. 1. Almost all the attacks that are applicable to web application. 2. Xpath/XML Injection 3. LDAP Injection 4. Exploiting XML parsers 5. Brute forcing
    11. 11. Exploiting XML parser Document Object Model SAX Buffer overflow XML Injection
    12. 12. Error handling  Uncaught exceptions within application logic are caught at the SOAP engine and displayed as a SOAP fault element. Defense ○ Ensure all exceptions caught are generic error messages returned with SOAP responses. ○ Suppress exception details from being included in the fault element.
    13. 13. Attack simulation Technique and Tools  Foot printing Discovering the existence of some services relevant to the target. Discovering the entry points to those respective services. ○ Techniques based on the UBR (Universal Business Register) and UDDI will work ○ WSDL scanning and schema poisoning ○ Discovery of .wsdl, .jws, .aspx  Tool: wspawn – It does footprint via the UBR(UDDI) inquire API’s. It also does discovery based protocol. Enumeration ○ Service Information ○ Port type information ○ Operation information
    14. 14. Simulating the attack DEMO
    15. 15. Other tools  Commercial Tools: WebInspect WSID4ID (Web services interface Definition for intrusion Defense)
    16. 16. Conclusion  We can now attack web services 
    17. 17. Any Questions ??
    18. 18. WCF Services/Security