Most of the time folks find it really difficult to test web services. It is because we don't have proper knowledge of web services. Before any testing it is important to understand the system, we should know what can be the positive and negative sides of the technology and implementations of that application. Lets dive into the depth of web service testing. To provide a better security solution to the web service we should  have a brief understanding of web services, their architectural styles, their constraints and their characteristics that are responsible for their strength as well as weakness.

---

What is web service?

Web Services are web application components. A web service is a collection of open protocols and standards used for exchanging data between applications and systems.Web service has been developed to provide interoperability among various platforms since it has been using open standard protocol (XML, HTTP). 

You can build a Java-based Web Service on Solaris that is accessible from your Visual Basic program that runs on Windows. You can also use C# to build new Web Services on Windows that can be invoked from your Web application that is based on Java Server Pages (JSP) and runs on Linux.
Web service can be used for transferring data between two web applications running on heterogeneous platforms. In simple terms Web service is way of calling a function fun1() inside a software S1 by another software S2. Both the software are present in different machines. S1 is written in java and S2 is written in .net. 

Difference between web application and web service:

• Web application requires application to be accessed through web browser on client side, whereas web service initiates machine to machine communication on internet. 
• It is must for web application to have a GUI but a web service may not be necessarily having a GUI.

The web services are of two types

• REST
• SOAP

SOAP (Simple Object Access Protocol):

Taking the above example in consideration, for establishing a communication between S1 and S2 there needs to be a medium and a format (for input and output). The medium is internet over HTTP and the format for input and output is SOAP. 
It’s an XML based protocol used for sending information over HTTP. Web services use SOAP format to send XML request.  For accessing SOAP we require some details related to web service and the location where it is hosted. These all are contained in WSDL(Web Service Description Language).
In depth discussion on SOAP will be included in upcoming posts. 

Sample Request and Responses:

REST:

ReST stands for Representational State Transfer Protocol. It contains the set of guideline how client and server will interact with each other.ReST is an architectural style for designing networked applications. It uses HTTP protocol to make calls between two machines. Restful services use HTTP to post (insert and update data), read (make queries) and delete data.

Constraints of ReST Architectural style
1.    Null Type Architecture:
 The Null style is simply an empty set of constraints. From an architectural perspective, the null style describes a system in which there are no distinguished boundaries between components. 
2.    Client Server Architecture:
 The uniform interface separates clients from servers. The client is not concerned with the data storage in server and servers are not concerned with the user interface or user state.
3.    Stateless:
The necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers.
4.    Cacheable:
Clients can cache responses. Responses must be defined as cacheable or not, to prevent adversary from stealing a stale data.
5.    Uniform Interfaces between the components:
Defines the interface between the client and server. The four guiding principle –

•  Resources in rest are identified by URI as resource identifier. 
•  A client if possessing representation of a resource he can manipulate it if he has a permission to do so.
•  ReST uses Self Descriptive Messages which means every request includes enough information to describe how to process the request. 
• ReST follows HATEOAS(Hypermedia as the Engine of Application State) i.e. Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. This is technically referred-to as hypermedia (or hyperlinks within hypertext).

6.    Layered System:
A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Layers may also enforce security policies.

7.    Code on Demand(optional):
A server can customize or extend the functionality of client by transferring a logic to it that can be executed. 

Sample Request and Responses

Dissecting ReST-

•   Resources: ReST guidelines says the data and functionality which a client can access from server is termed as Resources. Resource must be accessed by using its URI by all the clients. This is very much similar to HTTP . When a client sends a request to the server, it gets a response by server which is the representation of resource. A resource can be represented in HTML, XML, plain text, JSON etc. Restful web services express resource typically as noun.

•   Representation: A representation is a document that captures the current state of a resource. For example an HTML web document containing information(state) about a book you are interested in. ReST is typically transfer of representation of resource in request and response.

•    Rest Verbs: ReST uses HTTP verbs to identify what you want to do with a resource. They can perform all four crucial operations on resources(CRUD -Create, Read, Update, Delete). Listed are the verbs used by ReST.

1. GET: the verb is used to fetch a resource.

2. POST: the verb is used to create a child resource at server defined URL.

3. PUT: the verb is used to create /update a resource in its entirety at client defined URL.

4. DELETE: the verb is used to delete a resource.

5. PATCH: the verb is used to update part of resource at client specified URL.

•    Understanding status code
1.     200 OK
2.     201 created
3.     204 No content
4.     304 not modified
5.     500 internal server error
6.     501 not implemented
7.     401 not authorized
8.     400 bad request
9.     403 forbidden
10.   404 not found
11.   405 method not allowed

Rest  versus SOAP
(Assuming that reader is having a knowledge of SOAP ) 

1.    ReST Services are light weighted. They give faster results by involving simple transaction(CRUD operations). SOAP uses interfaces and named operations to expose business logic. ReST uses (generally) URI and methods like (GET, PUT, POST, DELETE) to expose resources.

2.    ReST Services are simpler as compared to SOAP.

GET  /example/Customer/1 

 Basic Request of ReST is much more simpler than that of SOAP.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
      <soapenv:Body>
         <tem:Customer>
             <!--Optional:-->
         <tem:uid>1</tem:uid>
      </tem: Customer >
   </soapenv:Body>
</soapenv:Envelope> 

3.    SOAP supports several protocols and technologies , including WSDL,XSDs, SOAP,WS-Addressing. Whereas ReST is mainly dependant on HTTP.

4.  Most real-world applications are not simple and support complex operations, which require conversational state and contextual information to be maintained. With the SOAP approach, developers need not worry about writing this plumbing code into the application layer themselves.

5.    ReST does not enforce any message format such as XML or JSON or etc. Whereas, SOAP is XML based message protocol.

6.    ReST follows stateless model. SOAP has specifications for stateful implementation as well.

Security concerns of ReST:

Various security concern of ReST is stated as:
1.    No built-in security features 
2.    No encryption 
3.    No session management 
4.    It is cacheable 
5.    It runs over HTTP
6.    Statelessness of Rest brings in security concerns
7.    Custom Authentication (if used)

The above listed was a brief description of weaker side of ReST that can lead to its exploitation. In the upcoming blog we will see  how a weakness in ReST service implementation can be a cause of multiple vulnerabilities.

Reference:
http://www.restapitutorial.com/lessons/whatisrest.html#
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.html