Web services
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 among themselves. It allows consumers over the internet to access data without the application knowing the format or the location 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:
- Simple object access protocol (SOAP)
- RESTful web services
Introducing SOAP and RESTful 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:
- Works really well with CRUD operations
- Better performance and scalability
- Can handle multiple formats
- Smaller learning curve
- Design philosophy similar to web applications
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 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:
Securing web services
RESTFul web services should be protected against the following security issues:
- The session between the consumer and the provider of the web service should be authenticated and maintained using a session token or an API key. The API key, username, and session token should never be passed in the URL. The session state should always be maintained on the server side and not the client side. RESTful services does not provide any security by default it is dependent on transport layer security to protect the data while it on the wire. SSL is recommended to protect the data in transit. SOAP web services use WS-security which provides message level security that is more robust than HTTPS. You should never pass an API key in the URL as SSL does not protects the URL parameters and the key is logged in bookmarks and server logs. Either OAuth or HMAC authentication should be used. In HMAC
- Most tasks of a RESTFul web services are done using the 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:
- GET To retrieve data
- PUT To insert data
- POST To update data
- DELETE To remove data
- The web service should be tested using random generated data to verify the implementation of validation filters. Input fields taking a finite number of characters should use the whitelisting-based approach. Using this approach, we can define what is acceptable and build a list of legitimate input accepted by the application. Any characters or untrusted data not part of the whitelist is rejected.
- If the web service is using XML, it should be tested against common XML-based attacks such as XPath injection, XQuery injection, XML schema poisoning, and others.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:
Insecure direct object reference vulnerability
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:
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.