How to Secure (ReSTFul) Web Services
Application security is now one of hottest topic in IT departments. We are now fully in the age of the Service Oriented Architecture (SOA) regardless of how it has been rebranded by the marketing departments. It is the norm to build services and provided them to our clients, partners and suppliers. Retailers such as Amazon have open their door through their API to third party developers to make use of their vast resources; be it cloud computing or selling and buying items. We build services and make them available through (a well designed) application programming interface (API). There is a downside in making our API available to third parties, and that is we are making ourselves vulnerable to attackers to compromise our systems. This post aims to discuss ways to secure web services against such malicious behaviour. Remember, nothing is secured in theory but let’s make it darn hard to break it in practice. The security has to be a forethought when starting to develop a new service.
There are three layers of security to be addressed while developing APIs and making them available over the internet to third party users;
These layers are also applicable to SOAP based web services and any network distributed systems. The above diagram shall be read bottom up. Even though the above layers look and sound similar to the OSI Model, there are not the same and should not be confused.
When making a service available over a network, we are utilizing the transport layer. The role of the transport layer is to ensure that third party clients can make a reliable connection to our services. Therefore, the transport layer creates a communication link between our API and consumers. In the context of web services, our communications link is created over HTTP. We all know that HTTP in its barebones is not secured but we can still observe people making their APIs available over plain HTTP. It’s possible that your company has developed its own proprietary encryption which can be added to the HTTP communication but in any cases, here are the most common ones:
- HTTP over SSL (HTTPS)
- HTTP over TLS (HTTPS)
Legacy network applications which communicates over the internet using HTTP were mostly secured using Secure Socket Layers (SSL). Certificates vendors branded their products as SSL certificates, therefore when the Transport Layer Security (TLS) was introduced, they kept the same name as SSL certificates. TLS is the evolution of SSL, needless to say that all APIs communications shall be done over HTTPS preferably using TLS as it has fixed some of the vulnerabilities of SSL.
Clients initiates communication with web services through the transport layer by using the web services URI. Once the connection is established; the client is then forwarded to the presentation layer where requests can be made. Depending on the system architecture and the purposes of the web services, the client can either make anonymous or authenticated calls. Protected web services calls shall be available only to authenticated parties. The most common way to block anonymous callers from making restricted calls is to force them to confirm their identity. Here are three common ways to validate third party callers:
- Basic Authentication: the web services would request that the third party caller identifies itself by providing a valid username and password combination which would be used to create a session for the duration of the communication
- OAuth 1 or 2: OAuth allows third party client to access users resources without sharing their credentials. It is commonly used by web services such as Facebook, Twitter and LinkedIn to authorise third party applications to log onto their sites.
- Identity Certificate: identity certificates are, in many forms, similar to SSL certificates. The Certificate Authority (CA), which could be your company, signs and endorse the certificate on behalf of a third party. You can provide your third party with an identity certificate that you have signed with your key. This could be very secured in the same way as HTTPS. Third party clients should not self signed their certificates. As the certificates are available on the callers’ devices, if a device is stolen, this can become a security risk.
A recommendation would be to secure your web services API with Basic Authentication over HTTPS, this security approach is the most popular and tested on the internet. OAuth v1 would be recommended over v2 for transmitting highly sensitive data. OAuth suitability on commercial APIs is questionable as opposed to web site which aims is amassed a large user base.
This layer has been ignored in most conversation about web services security. A simple Google search on web services security would show results which only addressed the transport and presentation layer. So why would you want to discuss ‘securing the web services at the application layer’? This is as important as the two previous layers. Let’s put it into context; a third party client ‘s systems have been compromised. The attackers were able to obtain some credentials to our web services. As we do not have any application layer security in place, the attacker can connect to our services and make all sort of requests. This is a fictitious yet very probable scenario. So let’s tackle how we handle user authorisation in our web services, remember that authorisation is the process of verifying that you have access to something. Here are two possible solutions:
- Digital Asset Manager (DAM)
- Custom development
The application layer security would group, roles, domain or hierarchy level security. It is faster and cheaper to build a custom solution or procure an Open Source alternative. Regardless of the which route you may venture into, application layer security has to be implemented to have a fully secured web services.
We have discussed the three layers of web services security. Remember that; in theory nothing is secure but we should make near impossible to break it in practice. Architects have to consider all three layers when designing APIs which would be available to third parties over the internet. All web services communication shall be conducted over a secured channel such as HTTPS. The Basic Authentication can handle most authentication requests to web services and is a secure way to exchange user credentials over HTTPS. Application Layer security shall be implemented to handle authorisation to resources. Remember, code defensively to mitigate risks of a security breach.