This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Web Service (XML Interpreter)

From OWASP
Revision as of 15:06, 17 October 2012 by Tom Eston (talk | contribs)

Jump to: navigation, search
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

4.10 Web Service Testing


Web Services are implemented by adding XML onto layer 7 applications such as HTTP. For example, the most common application that is used in web services is HTTP. The XML is constructed in a specific manner so that the sender and receiver of the message can understand its contents. The XML structure is known as SOAP, which stands for Simple Object Access Protocol. The method in which SOAP is used is not the same manner that web applications are used. Rather than the traditional request response, web services should be thought of more like SMTP. SOAP is more like SMTP because the server can easily forward the SOAP message or envelope onto another web service in-order to receive a response.

Any data being transmitted between a user and web services should be reviewed to ensure that all data is protected from being intercepted by a malicious attacker. One common misconception is to use BASIC Authentication to restrict access to other authorized users. Depending on the architecture of the web service and the nature of its use, BASIC Authentication may not be acceptable. Let us assume there is a web service that is exposed to the Internet and utilizes BASIC Authentication. If a use of the web service is done from a mobile device, then it would be possible to intercept the credentials being used. This could be done by performing a man-in-the-middle (MiTM) based attack.

The following articles describe the web services testing:



Key Points Regarding Web Services

SOA (Service Orientated Architecture)/Web services applications are systems which are enabling businesses to inter-operate and are growing at an unprecedented rate. Web services are typically used in modern mobile applications utilizing SOAP or RESTful protocols. Webservice "clients" are generally not user web front-ends but other backend servers. Webservices are exposed to the net like any other service but can be used on HTTP, FTP, SMTP, MQ among other transport protocols. The Web Services Framework utilizes the HTTP protocol (as standard Web Application) in conjunction with XML, SOAP, WSDL and UDDI technologies:

  • The "Web Services Description Language" (WSDL) is used to describe the interfaces of a service.
  • The "Simple Object Access Protocol" (SOAP) provides the means for communication between Web Services and Client Applications with XML and HTTP.
  • "Universal Description, Discovery and Integration" (UDDI) is used to register and publish Web Services and their characteristics so that they can be found from potential clients.

The vulnerabilities in web services are similar to other vulnerabilities, such as SQL injection, information disclosure, and leakage, but web services also have unique XML/parser related vulnerabilities, which are discussed here as well.

Differences in Web Service Standards

Over the last several years there has been a departure from the traditional XML based SOAP web services. Traditional SOAP based services (depending on the application) have become a hindrance for some developers because these services can add extra bandwidth and overhead to data exchange. These issues have lead to the emergence of more RESTful web services such as JSON (JavaScript Notation). REST (Representational State Transfer) services like JSON use HTTP methods (GET, POST, PUT, DELETE) for data exchange. However, SOAP based web services remain popular and are found being used for commercial as well as custom created applications. Some examples of SOAP web services used on a large scale include Amazon EC2, PayPal and Microsoft Azure . The bottom line is that SOAP based web services generally offer more complex data structures than their REST counterparts regardless of latency and performance issues.

References

Whitepapers