vault-safe-cloud-security

How to Secure (ReSTFul) Web Services

Introduction

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;

Web Services Security 3 Layer

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.

Transport layer

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:

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.

Presentation Layer

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.

Application Layer

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:

  1. Digital Asset Manager (DAM)
  2. 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.

Conclusion

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.

Java-risk-715144

Hacking Liferay – Securing against online vulnerabilities

This is a brief post on securing Liferay on Tomcat and MySQL.
Liferay CE is stable enterprise portal, as more companies
start to adopt it, therefore security becomes a very important aspect of the
deployment. I am not sure if Liferay has been officially tested by a 3rd
party security firm but based on my simple security test against OWASP  Top 10 vulnerabilities, I can say that it looks good in that aspect. Some of the recommendations are taken from their
respective sites while others are based on our testing. We tested the following
on Linux Ubuntu 12.04 LTS.
Here is what I did for a quick test (using default
installation of liferay-portal-tomcat-6.1.1-ce-ga2-20120731132656558) :
1-
Download the Zed Attack Proxy (ZAP) from OWASP
2-
Make ZAP is set to run the following attacks:
a.
Path traversal
b.
Remote file Inclusion
c.
URL Redirector Abuse
d.
Server Side Include
e.
Cross Site Scripting
f.
SQL Injection
g.
Directory Browsing
h.
Session ID in URL rewrite
i.
Secure page browser cache
j.
External redirect
k.
CRLF injection
l.
Parameter tampering
3-
Run Liferay with default settings
4-
Now sit back and watch Liferay logs go “CRAZY”
Passing the OSWAP Top 10 vulnerabilities doesn’t mean that
you are out of the water yet. This test just focuses on browser based
penetration tests.
Here some steps to have an even more secured Liferay
deployment on Tomcat.

Make sure Tomcat uses SSL
to serve Liferay content

Make sure that you do not run Tomcat as “root”
user
o
Tomcat user should not have remote access to the
server

Disable auto-deployment of web applications

Change the file permissions on the Tomcat folder;
all Tomcat files should be owned by “root” user with group Tomcat  and
whilst owner has read/write privileges, group only has read and world has no
permissions. The exceptions are the logs, temp and work directory that are
owned by the Tomcat user rather than root. This means that even if an attacker
compromises the Tomcat process, they can’t change the Tomcat configuration,
deploy new web applications or modify existing web applications. The Tomcat
process runs with a umask of 007 to maintain these permissions.

Enable
Tomcat Security Manager, this causes web application to be run in a sandbox

In Server.xml
do the following:
o
Disable the
shutdown port by setting its attribute to -1
o
Make
sure that Tomcat HTTP connectors only to designated IP address; by default the
connectors listen to all configured IP addresses
o
Configure
the “ciphers” attribute used for SSL connections. By default, Tomcat uses the
default ciphers for the JVM which contains weak export grade ciphers
There are more
Tomcat settings which is available online.
You also need to
make sure that you secure your Operating System and Network. Now that we have
some basic security in place for Tomcat, let’s now tackle the our database. In
this test, we used MySQL 5.
Here is some basic
MySQL security:

Set a
root password for MySQL

Remove
all anonymous accounts

Disable
non-local root access

Remove
all test databases and any access rules related to them

Reload privilege
tables to apply the changes

Enable
SSL connection for MySQL, the default connection
is unencrypted
Now to conclude, let’s
secure our Liferay instance. Liferay is configured through portal.properties
and you should override those settings in portal-ext.properties. Create the
file if it doesn’t exist:

Set web.server.host=MY-HOST-NAME
so that it is not dynamically set

Set the preferred
protocol to web.server.protocol=https

If you
want Liferay to be only accessible from certain IP addresses, set
main.servlet.hosts.allowed=,,

To make
Liferay only accessible through HTTPS, set main.servlet.https.required=true

Secure the
Axis servlet as follow:
o
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP
axis.servlet.https.required=true

Secure
the JSON Tunnel Servlet as follow:
o
json.servlet.hosts.allowed=
json.servlet.https.required=true

Secure Liferay Tunnel Servlet as follow:
o
tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP
tunnel.servlet.https.required=true

Secure Spring Remoting Servlet
o
spring.remoting.servlet.hosts.allowed=127.0.0.1,SERVER_IP
spring.remoting.servlet.https.required=true

Securing the Webdav Servlet
o
webdav.servlet.hosts.allowed=
webdav.servlet.https.required=true

Make sure you have configured the Admin
portlet by overriding all the default values

The IFrame Portlet, when used in a high
security environment, should have the following properties set
o
iframe.password.token.role=

JAAS security need to have properties set:
o
To stop user from passing in encrypted
password: portal.jaas.strict.password=true

Passwords: Choose a strong password
encryption algorithm to encrypt passwords by setting the following:
o
passwords.encryption.algorithm=
I am sure that many
other security settings are left out so feel free to share in the comments. I
hope this helps someone to secure their Liferay environment.

A software architect is not a senior developer

There are some IT departments till this day who believes
that by hiring a senior developer they can fulfil the role of a software
architect.
Senior developers have much knowledge about the full
software lifecycle and can be trained to be architects but are they are not. A software
architect first and foremost is a visionary. It helps that an architect has some
software development experience but most of the time, he will be exposed to a
polyglot environment. Before a single line of code is written, the architect
will have to map out how the business requirements can be translated into a
solution. This not only requires knowledge of the business environment, from
operations to infrastructure, but to present a convincing system to the
stakeholders. Requirements such as scalability, latency and security will be
missed from initial development stage if not tackled early on. Senior
development understands their team and their abilities. Senior developers can
manage workloads amongst team members and make sure that the under-development project
meets its architectural goal.
The architect will decide how a requirement should be
developed in order to meet the business requirement as an example:
The business has
offices around the globe, the business requirements require the website to be
fully loaded within 3s regardless of the location of the user and handle a
minimum load of a hundred thousand users. 
The above requirements are dealing with the architecture of
the system not that we can authenticate a user against an Oracle DB.
It is important to note that many Software Architect were
previously working as Senior Developer (such as myself) but nonetheless, many
senior developers have no interest in architecture. Choosing if a system should
use Tomcat or Glassfish and Apache Webserver for load balancing is the domain
of the Architect. Doing code review and making sure software development
pattern are well applied, is the domain of Senior Developer. A senior developer
can also choose a development methodology such as SCRUM with the approval of the
Project Manager. The architect would attend meetings with the various
stakeholders: end users, operation, infrastructure, development and testing
teams. When the business asks why is the system slow, they will turn to the
architect. The architect would then have to sit down with the lead senior
developer and review that the current development meets the architecture goals
or if there are faults in the architecture design.
I am a software architect and I can easily communicate my
vision to the development team but I am also a senior developer who still loves
hacking the machines. I worked in an architecture committee and came across
architects who have no development experience which I think it is wrong. An
architect should appreciate other development languages not to be biased toward
a single one without any merit.
I hope that more companies will appreciate the role of
software architects in software projects regardless of its size.