Web services are based on a service oriented architecture. Service-oriented architecture allows a service provider to easily integrate with the consumer of that service. Web services enable different applications to share data and functionality amongst themselves. It allows consumers over the internet to access data without the application knowing the format or the location of the data.
This becomes extremely critical when you don't want to expose the data model or the logic used to access the data but still want the data readily available for its consumers. An example would be a web service exposed by a stock exchange. Online brokers can use this web service to get real time information about the stocks and display them on their own websites for end users to buy. The broker website only needs to call the service and request the data for a company. When the service replies back with the data, the web application can parse the information and display it.
Web services are platform independent, the stock exchange application can be written in any language and you can still call the service regardless of the underlying technology used to build the application. The only thing the service provider and the consumer should agree is the rules for exchange of the data.
Some people confuse web services as a form of web application; a web service does not contain a GUI because it is only a component consisting of managed code that can be accessed remotely using HTTP by the web application. It allows web applications to access and request data from third-party service providers that may be running on an entirely different platform.
There are currently two different ways to develop web services:
SOAP has been the traditional way of developing a web service, but it has many drawback and applications are now moving over to the RESTful web service. XML is the only data exchange format available when using a SOAP web service, whereas RESTful web services can work with JSON and other data formats. Although SOAP-based web services are recommended in some cases due to the extra security specifications, the lightweight RESTful web service is the preferred method of many developers due to its simplicity. SOAP is a protocol, whereas REST is an architectural style. Amazon, Facebook, Google, and Yahoo! have already moved over to RESTful web services.
Some of the features of RESTful web services are as follows:
The major advantage that SOAP has over REST is that SOAP is transport independent, whereas REST works only over HTTP. REST is based on HTTP, and therefore the same vulnerabilities that affect a standard web application could be used against it. Fortunately, the same security best practices can be applied to secure the REST web service.
The complexity involved in developing SOAP services where the XML data is wrapped in a SOAP request and then sent using HTTP forced many organizations towards REST services. It also needed a WSDL file that provided information related to the service. A UDDI directory had to be maintained where the WSDL file is published.
The basic idea of a RESTful service is, rather than using a complicated mechanism such as SOAP it directly communicates with the service provider over HTTP without the need of any additional protocol. It uses HTTP to create, read, update, and delete data.
A request sent by the consumer of a SOAP based web service is as follows:
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body sp="http://www.stockexchange.com/stockprice"> <sp:GetStockPrice> <sp:Stockname>xyz</sp:Stockname> </sp:GetStockPrice> </soap:Body> </soap:Envelope>
On the other hand, a request sent to a RESTFul web service could be as simple as this:
http://www.stockexchange.com/stockprice/Stockname/xyz
The application uses a GET
request to read data from the web service which has low overhead and is also easy for the developers to code unlike the SOAP request, which is long and complicated. While RESTful web services can also return data using XML, it is rarely used—JSON is the preferred way of returning data.
In a real-world scenario, you would be encountering more applications where you need to understand how the web application interacts with the web services and identify if there is any vulnerability that an attacker can exploit. RESTFul web services should be protected against the following security issues:
GET
, POST
, DELETE
, and PUT
methods. For example, in a stock exchange web service an anonymous user may be allowed to use the GET
method to query the stock value, but the PUT
or DELETE
methods should never be allowed for a non-authenticated user. The web service should be careful when allowing multiple methods for a given URL. For a method that is not allowed against a URL, a forbidden message should be sent back. For critical tasks involving the PUT
and DELETE
methods, a random token should be used to to mitigate a CSRF attack. Most web services use the following four verbs:
HTTP verb |
Use |
---|---|
|
To retrieve data |
|
To insert data |
|
To update data |
|
To remove data |
When there is an exception, the RESTful API should respond back with appropriate error messages just like it is done in regular web pages and use the HTTP status codes to return errors to the clients. In the exception message, you leave as little server information as possible. Here are the response codes:
Response code |
Meaning |
---|---|
100s – Information |
We're all cool |
200s - Success |
I got what you need |
300s – Redirection |
It's over there |
400s – Client error |
You messed it up |
500s – Server error |
I messed it up |
Insecure direct object reference vulnerability is not specific to RESTful web services but is prevalent in it. We are familiar with e-commerce applications that display a product and information about it. Most likely, the developer would have used a unique ID to identify the product at the backend. This ID also identifies the product when stored in the database by the means of a primary key. Hence, the ID becomes a direct object reference.
In an e-commerce application that uses web services, the call to the API would look something like this:
https://example.com/product/234752879
The information of the product is then returned in JSON format, which is formatted and displayed on the client's browser:
{ "id": "234752879", "product_name": "webcam", "product _family": "electronics", "section": "computers", "Cost": "500" }
If you increment the product ID, the data for the product 234752880
is returned instead of 234752879
. This is not a big issue in this particular web application, but what if in a financial application you have a direct object reference to the account number that might store sensitive information and you are able to view data of other accounts by manipulating the account ID. Web services should only allow access after proper authentication; otherwise, you run into the risk of someone accessing sensitive data by using direct object reference. Insecure direct object reference is a major cause of concern in web services and should be on top of your to-do list when pentesting a RESTFul web service.
An application using a web service increases the attack surface and also changes the risk profile of the application. The testing methodology is not different from a normal web application and the application should still be tested against the OWASP top ten vulnerabilities.
18.119.138.202