journal of engineering the capabilities and vulnerabilities of

International Journal of Engineering and Technology Volume 2 No. 6, June, 2012

ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1062

The Capabilities and Vulnerabilities of the Cloud

Nigel McKelvey, Eamonn Houston-Callaghan Letterkenny Institute of Technology, Port Road, Letterkenny, Co Donegal, Ireland

ABSTRACT

Cloud computing is currently a growing sector in IT. This paper will outline the steps involved in developing and deploying a

secure application to a cloud environment. A series of penetration tests will be conducted and the results analysed and

documented accordingly. A further purpose of this paper is to expose security issues in the cloud and provide solutions to

resolve or reduce the impact of the issues on the client.

Keywords: Cloud, security, vulnerabilities, testing, Azure

1. INTRODUCTION

Cloud computing has been around for some time. The last

number of years have seen a steady rise in the number of

companies adopting the service. Cloud offers various

advantages to companies, in particular to small and

medium enterprises(SMEs) who are attracted to the cost

saving and flexibility that cloud has to offer. On the other

hand, many companies have raised concerns about the

security issues that cloud also presents and are

apprehensive about moving their data to the cloud. For

this paper, the development of a worthwhile software

artefact that is viable in today’s software industry was

designed. A software artefact was developed that was

used as a base for testing against the various security risks

that cloud computing imposes.

Testing the artefact with a range of testing tools was also

conducted and results analysed. The result of this paper

will provide businesses with sufficient knowledge to

make a decision about whether or not to embrace the

cloud and indeed which approach will best suit their

company. It is important to note that there is no universal

cloud solution for everyone, but certainly each solution

shares similar security risks.

2. RESOLVING ISSUES WITH CLOUD

How can you resolve issues that are not in your control?

Consumers often look at the provider when issues in the

cloud arise. While it is fair to say that the providers have a

responsibility to provide a secure service, clients must

first ensure that the application they wish to host on the

cloud is secure. Deploying a unsecured application to any

server, whether it is in house or cloud, would create

problems. While this may seem very obvious, it is an

important point nonetheless to make. Vulnerabilities in

software costs money when compromised. Microsoft

recently reported in their intelligence report that

application vulnerabilities accounts for 71.5 percent of all

vulnerabilities disclosed (Microsoft, 2011). With this is

mind, the software artefact that was developed had a key

focus on secure programming.

Many people would view Java as a secure programming

language, that was developed to overcome security issues

of preceding languages, such as C++. While this may be

true, the Java language is not fully secure. Security

vulnerabilities exist in common packages that are used in

the majority of web applications today (Livshits and Lam,

2005). That is not to dismiss the use of the Java language,

as its easy to code security features has made it a very

popular programming language for many businesses

today.

The purpose of this paper is to aid businesses in making a

decision on the move to the cloud and thus the software

artefact was developed using the popular web

development language, Java. Whilst Java is a secure

language, that does not exempt it from malicious attacks

such as SQL Injections and cross-site scripting. Logical

programming errors can also create vulnerabilities

(Livshits and Lam, 2005). Java is only secure if it is

securely written, which was fundamental in the

development of the software artefact. This involved

ensuring that the correct access control is set for classes

and methods and ensuring that classes are not immutable.

There are many forms of attacks that a hacker can use on

web applications, each of is examined and tested against

the software artefact.

International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012


3. OPEN WEB APPLICATION

SECURITY PROJECT

In a recent report by Williams and et al (2010b), the Open

Web Application Security Project(OWASP) provided the

top ten most common web security attacks. Every couple

of years, OWASP will release a updated list that

represents the collective judgment of many experts in the

field. The impact each attack has on a company range

from minor to severe. In any case, web security attacks

should try and be prevented, no matter what the potential

impact. Many attackers are professionals whose earnings

come from financial gain. Below is the top ten that will be

examined during the implementation of the software

artefact. There are without doubt more security issues out

there then the ten that OWASP have provided, but

certainly the top ten list is an ideal start to securing a web

application.

A1 Injection - currently at the top of all security risks is

injection, or more commonly known as SQL injection.

This form of attack is probably the most simple to

perform for attackers and can have severe impact on the

applications. One SQL injection can bring down an entire

server which can be very worrying if a consumer sharing

the same cloud server with you has not equipped itself

against an SQL injection. Many web applications interact

with a back end database through the use of dynamic SQL

statements. Unchecked input is widely reputed as the

source of web application vulnerabilities (Livshits and

Lam, 2005). Hackers can input malicious code to alter an

SQL statement before it is executed. This is a simple

technique that has been exploited for years when it can

easily be prevented with the use of prepared statements or

store procedures. Both prepared statements and stored

procedures produce them same result and against SQL

injections. The software artefact used prepared

statements.

A2 Cross-Site Scripting (XSS) is very similar to injection

attack. XSS is when an attacker injects malicious code

into web pages. Like SQL attacks, this can have severe

impact on a web application. Again, the same argument

mentioned above for SQL injection can be applied.

Sharing a server with an unsecured application would

provide a route for a hacker to attack. Indeed one

unsecured application hosted on the cloud could

potentially bring down more then one server, it could

bring down a cluster with the right malicious script. XSS

is a popular and easy way a hacker could inject one such

script into the cloud. Many of today’s well known

websites have been victim to XSS. One such example is

Yahoo, who refused to except an XSS flaw that was

exposed to them by a hacker at an hacking event they held

(Greenberg, 2011). The hacker later sold the worm on

twitter. The availability of such worms make this attack

so common and easy to exploit, which is why is the

second most common risk. XSS holes are created when

developers fail to properly validate. The only way to

prevent XSS is by using secure coding practices.

A3 Broken Authentication and Session Management

flaws can allow attackers to steal users identity and

impersonate that user. Any application that handles

sensitive data should focus on minimising the risk. The

application developed for this research is one such

example. If a careless user, say with administrative

permissions did not log off there account when in a public

place, a hacker could use that computer to get there

session and gain access to an authorised account. There

are simple steps that developers can take to prevent to

reduce the risk. Sessions should time out after so many

minutes. Ensure that all users’ credentials are protected.

Users should be prompted for strong passwords that are

not easily guessed. The passwords should be stored

encrypted or in hex form.

A4 Insecure Direct Object References is important to any

web application, in particular those that contain sensitive

data, to only allow authorised access to files. Can a hacker

gain access to restricted resources by simply changing a

parameter value to references it? Consider a cloud server

that is hosting a vulnerable applications that uses a

parameter to access a file.

http://vulnerable-application.com/file.jsp?file=.txt

The attacker simply modifies the file parameter to send a

request for a file that they are not authorised to view. For

example, the attacker can send the following parameter to

access a file such as tomcat/conf/tomcat-users.xml.

http://misc-security.com/file.jsp?file=../../../conf/tomcat-

users.xml

With the list of user credentials the attacker now has

access to the server. Applications should check

authentication when handling request. Object references

such as primary keys, should never be exposed to the user

in URLs or any other form. Requests should be checked

for authentication before returning any object.

A5 Cross-Site Request Forgery (CSRF) is a lot like XSS.

The distinction between the two is that CSRF exposes

vulnerabilities on the server side, not the client side. A

CSRF attack tricks the server into processing a user

request that has been sent by an unauthorized user. By

including a valid session id in the HTTP request, the

server would think that the request is genuine and proceed

with the process. Simply removing the session id from the

url and setting it as a cookie does not prevent CSRF. The

only method that works is the inclusion of a random token

with every request, one that can not be guessed by an

attacker. This token can then provide authentication that

the request has been sent from the authorised user.



A6 Security Misconfiguration is probably the easiest risk

to prevent. Configuring all software and hardware to

include the latest security patches is a simply task that

many companies don’t do. Often when the system is up

and running, developers would be apprehensive about

upgrading to the latest version in fear it would cause

compatibility issues with other software used in the

application. If a patch is released to fix a security issue

that has been identified that it is important to download it,

as opportunists would be looking to exploit known

vulnerabilities.

A7 Insecure Cryptographic Storage. Encrypting data

provides security to ensure the data remains secure, but

only if the algorithm is secure. Weak algorithms can

easily be broken. Often secure algorithms are broken and

are longer secure. Companies should ensure that they use

secure algorithms. Often algorithms are broken by

hackers and deemed insecure to use. Again this is where

the importance of security misconfiguration is

highlighted. The software artefact used the Advance

Encryption Standard (AES).

A8 Failure to Restrict URL Access often results in

resources being obtained by unauthorised users. If objects

are not secured, then it is no surprise opportunists will

retrieve them. The common security by obscurity

approach by developers is not sufficient enough, not least

on a cloud application hosting more then one application.

Enforcing access control is probably the best way to

defend against this attack.

A9 Insufficient Transport Layer Protection allows

unsecured communication over the internet to be exposed.

It provides attackers with easy access. To prevent this, the

web application will use Transport Layer Security(TLS)

to provide encryption at the transport level. Without the

use of encryption, all communications between a client

and server are sent in plain text. This is a problem when it

comes to cloud applications, as the cloud could be

communicating from the other side of the globe, passing

through many to reach its destination. and if unencrypted,

both the client and the cloud provider can be

compromised.

A10 Unvalidated Redirects and Forwards can take a user

to phising sites. If the web application does not implement

proper validation, then an attacker can redirect users to

harmful sites or use forwards to grant them access to

pages they are not authorised to view. The easiest way to

prevent this is simply not having redirects or forward in

the application. If they are needed, ensure that the

destination is not set to a parameter. In rare cases where a

parameter is required to decide the destination, then

implement a validation method to check if the parameter

it is valid or not. This is the easiest vulnerability to

prevent, hence why it is last in the list of vulnerabilities.

Why secure the a application that is hosted on the cloud?

Who else is going to secure it? As mentioned earlier,

cloud users “cannot shift blame to their cloud service

provider if things go wrong” Ashford (2011). If

developers target securing the top ten list, many common

vulnerabilities will be prevented. Vulnerable web

applications deployed on a shared cloud present risks not

only to their own users, but also to other applications

deployed on the cloud. Securing web applications is an

elusive goal. New vulnerabilities will be uncovered and

indeed old ones often appear after bypassing the

developers attention. Even the most secure applications

will eventually be succumbed by attack. When this

happens, sensitive data often is exposed. Recovering a

website from by a DDoS can cost companies time and

money. Client data however can be recovered once it is

stolen. It is important for every company to ensure that if

data is stolen, it is of no value to the attacker without a

key to decipher the data.

4. ENCRYPTING DATA IN THE CLOUD

Encryption has been used for years to tackle data security.

Sending encrypted data to the cloud will mean that the

data is more secure, as any data that goes missing will be

of no use to anyone without the key to decrypt it. This is

assuming of course that the encryption algorithm is strong

and only authorised users have the key to decrypt the

cipher text back. So now the company and their clients

feel safer about outsourcing their data and the privacy

issue has been resolved. But does this solution really

solve anything?

Consider the software artefact for this paper. The artefact

is a file hosting system that simply lets users store files in

the cloud and retrieve them when they need them. If a

client was worried about the security of the data in the

cloud, they could encrypt the data, so that he data would

be of no use to anyone who gets access to it. This eases

customers concerns but what benefit does it really offer

them. Every time they requires a record, they will have to

pull back the encrypted data, decrypt it and process it

before finally encrypting it again to send it back to the

cloud.

This is not making good use of the clouds service as it

presents more processing to be done by the user. Unless

the cloud is provided with the key to decrypt, which of

coarse leads us back to the problem in privacy concerns, it

remains rooted to square one. With this, the cloud can not

perform any processing unless the data is in plain text.

However, recent developments have seen the possibility

of developing a solution to this problem.

Processing encrypted data A recent thesis by Craig Gentry

has presented the possibility of processing encrypted data

without making the cipher text undecipherable (Gentry,

2010). He presents the first “homomorphic encryption

scheme”(FHE) that is proven to be able manipulate

encrypted text without losing the ability to decrypt it back

to readable code. The new findings allow the cloud to



process data it stores without ever seeing plain text. The

idea was originally proposed by Rivest, Adleman and

Dertouzos who were unable to implement a solution.

Gentry created a scheme that has slow processing

limitations.

Gentry’s thesis outlines the complex algorithm used to

execute his scheme. He uses an fictional story to illustrate

the idea of the FHE. The story describes Alice, who owns

a jewellery store. Concerned with the risk of getting other

workers to assemble her precious jewellery, she places it

in transparent glove box that allows the workers to use the

gloves to assemble the jewellery, without getting direct

access to it. Gentry makes it clear that the story indeed

does not fully explain the algorithm, but it does give an

indication of the original approach.

Currently, the idea is possible and has certainly been

proven to work. However, getting it to work for even

simple processing requires a huge amount of processing

power that very few companies would have access too.

For the chosen few that do have the convenience of large

super computers, the cost of using so much power for

every task would have a large impact on user response

times and energy consumption (Baliga et al., 2011).

Considering the rapid development of computers over the

last quarter century, the next number of years could see

new technology capable of such processing power. Indeed

refinements to the method could see less processing

power required. A more efficient method would obviously

reduce the need for the high levels of processing power.

For now, the idea is not reachable to companies seeking

the benefits of the homomorphic encryption algorithm but

nonetheless is a solution that would overcome the issue

that seems imminent in the future.

5. STANDARDISING THE CLOUD

As outlined throughout this paper, there is currently no

standard in place for cloud computing. Several

organisations have created guidelines for consumers to

check vendors are secure and reliable, such as Gartners.

This still does not ensure standards are met however. In

recent years, there have been many initiatives to try and

create a standard to ease security concerns in the cloud

and promote reassurance. Several infinitives were

developed to try and standardise the cloud. It seems some

what imperative to the clouds future that a standard is

created. What’s more, without a standard in place,

consumers will be unable to truly evaluate a providers

service. What do you base their service against if there are

no standards in place?

One particular initiative that aims to standardise the cloud

is the Cloud Security Alliance(CSA). The CSA was

formed nearly two years ago and has brought together

several stakeholders from all across the world. It aims at

defining cloud security frameworks. More notable, the

CSA has developed the Certificate in Cloud Security

Knowledge(CCSK), a recognised certification that

consumers can check their provider has. It is hoped that in

the next number of years a standard is set. Yale Li, Sr.

Security Architect for Microsoft Windows Azure is one of

the early adopters of the CCSK (Alliance, 2012). There

are other companies working towards standardising the

cloud that all share the same vision. The CCSK however

seems to be the leading standard as many of the major

players in cloud computing are collaborating with it.

Indeed any enterprise considering setting up their own

cloud should certainly be looking at adopting this

standard. Other companies are collaborating closely with

CSA and other organisations that working towards

standardisation.

However, there is a negative side to obtaining a standard.

It costs money. For a company to obtain the needed sign

off’s to use cloud-based computing, they must spend

money. This is not surprising of course, nothing comes

free in today’s world. The current difficulties are that the

company must do this for every cloud based product they

use (Levinson, 2011). Last year, the Federal Risk and

Authorization Management Program (FedRAMP)

released plans for a programme to ensure that federal

departments and agencies meet federal security guidelines

by establishing a framework (Ashford, 2010). The

framework aims to get agencies to cloud computing.

Currently, the plan is still in development with NIST and

other cloud experts (Anon, 2011). The purpose of

FedRamp is simply to provide cloud vendors with a

“process for obtaining an Authority to Operate (ATO) that

can be shared across agencies” Levinson (2011). This

process is a “Do Once, Use Many” that involves 4 steps,

initiating, assessing, authorizing, and leveraging.

FedRAMP certainly seems a good plan that could aid the

standardisation of the cloud. As stated at the start of this

paper, the consumer can not control the cloud. How do

you resolve issues that arise if outside of your control.

The best way to resolve a situation is to prevent it.

Encryption is a popular solution to resolving issues, as it

reduces the impact of it when something goes wrong.

Data is valuable and often sensitive. The majority of

cloud issues trace back to data privacy. It is hoped a cloud

standard will be developed in the coming years that can

ensure data is as safe in the cloud as it is in house. Until

that stage is reach, there will always be security issues in

the cloud.

6. THE SOFTWARE ARTEFACT

The software artefact is simply an application that allows

users to store files and access anywhere, providing a

testing bed for cloud computing vulnerabilities. Once the

application was fully tested, it was then hosted on the

cloud for further testing and evaluating. The reason

behind splitting the testing process into two sections is

simply to distinguish the application’s security



vulnerabilities from the cloud’s security vulnerabilities.

The results of the testing can provide an argument for the

adoption of cloud computing or indeed for an evaluation

of its use. The first part of any testing is to test that the

application works and that it can perform all of the

functionality that is expected from it. Below is the results

from the functional testing that was carried out.

Once the application passed the test, the next step was to

test the technical requirements, more specifically, test it

for security vulnerabilities. OWASP’s top 10 security

risks will be primary used to test this application for

vulnerabilities. To test each of the risks, a collection of

tools and applications have been used. These tools and

applications have been recommended by Russ McRee,

current manager of Microsoft’s Online Services Security

Incident Management team (McRee, 2011). The only

risks that will not be tested is Insecure Cryptographic

Storage and Failure to Restrict URL Access.

Cryptography is difficult to test other then brute force

attacks. The application does not have any restricted URL

pages such as administrative pages or a privileged

accounts thus the vulnerability can not be tested.

7. APPLICATION SECURITY TESTING

To begin the security testing, the application was tested

before being deployed to the cloud. Starting from the top

of OWASPs list, each risk is tested and then re-evaluated

after the results. It is important to note that all risks were

tested before any changes to code were made. The

purpose of this was to get more better indication of how

the application deals with each of the risks. Resolving a

fault for one risk could also resolve a fault for a different

risk.

7.1 Testing Tools

The following tools were used to test the application. All

of the tools are open source and easily obtained. Please

note that the Firefox add-ons were installed on version

3.6.28 as newer versions of Firefox do not currently

support some of the add ons.

Burpsuite version-1.4.01

Calomel SSL Validation (Mozilla Firefox add on)

Fiddler

HackBar (Mozilla Firefox add on)

Nikto-2.1.4

SQL Inject Me (Mozilla Firefox add on)

Tamper Data (Mozilla Firefox add on)

Watobo-0.9.7

7.2 Injection

SQL Inject Me is a Mozilla Firefox add-on that tests the

page that you are viewing from SQL Injection

vulnerabilities. The user can select which forms on the

page they want to test and whether they wish to execute

all tests or the most common tests.

Figure 1. SQL Inject Me

Each of the 3 pages of the application were tested against

all forms of attacks. Below is results from the first session

of testing.

Login Page

Figure 2. Test results from the Login page

Registration Page



Figure 3. Test results from the Register page

Home Page

Figure 4. Test results from the Home page

Overall, SQL Inject Me has reported 442 failures with the

application and 0 warnings. That seems a staggering

amount of failures for 3 pages. Altogether 380,120 tests

were executed, with 378,678 passes. However the

majority of these are most likely false positives. To

confirm this, each failure was examined. The failure

messages returned are either invalid bit length repeat or

Not in GZIP format, faces exception. These both relate to

java server faces, and are not actual sql injection

vulnerabilities. The use of prepared statements have

prevented any sql injection warnings. Secure coding,

making all variables private and final also aid the

prevention of database attacks.

8. CROSS SITE SCRIPTING (XSS)

To test for XSS vulnerabilities, OWASP ZAP was used.

The application crawls through the URLs of your web

application and returns any error alerts. Below is the

result from the first session of testing.

Figure 5. OWASP ZAP test results



In the alert window of the figure above, the application

returned the following warning message. A cookie has

been set without the HttpOnly flag, which means that the

cookie can be accessed by JavaScript. If a malicious script

can be run on this page then the cookie will be accessible

and can be transmitted to another site. If this is a session

cookie then session hijacking may be possible.

The problem was classed as a low risk. In the solution

window, ZAP provided the following action. Ensure that

the HttpOnly flag is set for all cookies. The application

also provided a link to their website with instructions on

how to set the HttpOnly flag (Williams and et al, 2010a).

The solution was simply to use the HttpOnly flag when

creating a cookie to moderate the risk of a script accessing

the cookie. The suggested solution below involved adding

a cookie config to web.xml. However the server threw an

exception after further research, it became apparent that

the glassfish server the application is deployed on does

not support HttpOnly flag.

<cookie-config>

<http-only>true</http-only>

</cookie-config>

This resolved the issue. Although the risk is classed as

low, it is still a application vulnerability, especially as one

of the cookies is a session cookie. Once deployed on to

the cloud, the problem will be examined again for a

solution. This vulnerability will not have a impact on the

cloud but is still a danger to clients if their session is

hijacked.

9. BROKEN AUTHENTICATION AND

SESSION MANAGEMENT

A lot of measures were taken during the design of the

software artefact to combat broken authentication, as

mentioned in section of the design chapter. Session

management is a common weakness that be exploited if

sessions are not correctly handled. To test how well the

strength of session ids, Firefox add-on Hackbar was

recommended as a tool for deciphering session id into

plain text. In the case of jsp, a random piece of data called

JSESSIONID is used. This can not be deciphered into

meaningful text as users are not always presented with the

same JSESSIONID each time they log in. With this, it is

hard to find an application to test broken authentication

and session management. To seek out any session

management security vulnerabilities in the application,

OWASP’s “Am I Vulnerable To Broken Authentication

and Session Management?” assessment questionnaire was

used (Williams and et al, 2010c).

a. Are credentials always protected when stored using

hashing or encryption? The application encrypts user

credentials before they are stored in the database

using AES. The strength of the algorithm was tested

and results can be seen in Insecure Cryptographic

Storage below.

b. Can credentials be guessed or overwritten through

weak account management functions? When a user

registers, they are prompted for a strong password

that must contain at least one upper-case character,

one lower-case character and at least one digit. The

users desired passwords are verified through he use

of regular expression that validates valid password.

This ensures that passwords are not weak and easily

guessed.

c. Are session IDs exposed in the URL? By default

tomcat does not expose the session id in URLS.

Instead, tomcat sets the JSESSIONID to a cookie. In

the case where the client has disabled cookies, tomcat

will append the JSESSIONID to the URL. To remove

the session id from the URL, Paul Tuckey’s Url

Rewrite Filter (Tuckey, 2005) was downloaded and

implemented. The open source filter simply rewrites

URLs before they are processed. The problem is the

application now depends on the JSESSIONID cookie.

If the client has cookies disabled, then requests can

not be processed. A warning message will be

returned to the client stating that they must enable

cookies to use the site.

d. Are session IDs vulnerable to session fixation

attacks? The least insecure method of storing session

ids is cookies (Kolsek, 2007). This makes the

application less vulnerable to session fixation attacks.

Kolsek (2007) emphasizes that preventing this form

of attack “is mainly the responsibility of the web

application, and not the underlying web server”. To

prevent session fixation attacks the application

implemented the following measures.

_ Session are destroyed when the user logs out of the

application. This forces the server to issue a new

session id upon each login. _ Sessions time out after

30 minutes. This prevents attackers from maintaining

trap sessions for long periods of time. Session time

outs also prevents attackers using old sessions from

users that forgot to log out of public machines. _

Session ids are not included in the URL.

e. Do session IDs timeout and can users log out? By

default, tomcat times the sessions out after 30

minutes. During testing, this value was set to 3 to

examine how the application reacts when the session

is timed out. The application simply freezes when the

session times out, and the table that displays their



files disappears from view. This is not a security

issue as such but certainly is a fault in the application.

Ideally, the user should be redirected back to the

login page when their session expires. To get this to

work, a filter was implemented that checks if session

is timed out when the user passes a request to the

server. If the session is timed out, the user is

redirected back to the log in page.

f. Are session IDs rotated after successful login?

Sessions are not rotated after successful login.

However they get destroyed after log out.

g. Are passwords, session IDs, and other credentials

sent only over TLS connections? The application

uses SSL(Section:2.4.1) for authentication and

confidentiality protection.

10. INSECURE DIRECT OBJECT

REFERENCES

A client should only be able to access their own objects,

the files that belong to their account. A common method

used by developers is posting the parameters with the

request. In the case of the software artefact, the

parameters used to reference objects are stored in the

session bean when the user logs in. This does not secure

the application but certainly reduces risk. Using Burp

Suite(2011),POST requests were intercepted. Below in

Figure 4.6, intercepted results show the two values being

passed into the web service can be seen in plain text. An

attacker can see that the web service requires a valid

client id and a file id to retrieve a file. If these values are

manipulated, then an attacking client could download

other clients files.

Figure 6. Burp Suite intercepted SOAP Message

During the design of the web service, the client id was

added to ensure that only the client id that belongs to the

file id will be accepted. This provides some basic

authentication check. If a attacker was able to manipulate

that parameters being passed in, then they could guess and

send a random client id and file id. To add to the security

of the application, the encryption was added to the body

of the SOAP message. Below in Figure 4.7, the

intercepted web service request is now encrypted, leaving

the attacker unaware of what parameters are being passed

into the web service. The message Body of the message is

signed, then encrypted, and then replaced with the

resulting xend:EncryptedData. The wsse:Security header

contains an EncryptedKey and a ds:Signature.

Obviously this increases the processing of every request.

This would not cause any strain on the cloud but could see

an increase in the cost for the extra server processing. The

added security can prevent insecure direct object

references, which can cause more damage then the cost of

implementing more authentication checking.

11. SECURITY MISCONFIGURATION

Watobo is a great tool for auditing a web application. It

checks web applications for security misconfiguration.

For the first audit of the application on localhost, Watobo

was configured to audit the software artefact. Its findings

are classed as vulnerabilities, hints or info. Although hints

and info can improve the performance of the application,



vulnerabilities is the main priority. Below, Figure 4.8 shows a vulnerability that was found in the application.

Figure 7. Encrypted intercepted SOAP Message

Figure 8. Watobo Security Audit



The application does not use SSL. The login page is

standard http. SSL was then added and tested against, see

Section 4.3.8 below, and the problem was resolved. Hints

and Info findings were also examined once SSL was

configured. None of the findings presented any

vulnerabilities and most related to performance in the

application.

12. CROSS SITE REQUEST FORGERY

(CSRF)

Testing tools used for CSRF test parameters used in

POST and GET requests. The application uses web

services and stores user values in a session bean. Because

of this, this feature could not be tested. However, when

researching prevention techniques, a CSRF vulnerability

in JSF was discovered. JSF includes a generated token,

thejavax.faces.ViewState. This token validates user

requests as legitimate or forged. This token was easily

guessable with old versions of JSF such as 1.2. JSF 2.1

resolved the problem. Unfortunately, the software artefact

is developed in jsf 1.2 and the IDE does not support the

upgrade to jsf2.1.

13. INSUFFICIENT TRANSPORT LAYER

PROTECTION

During the testing on localhost, a keystore named s1as

was created. The naming of the keystore was based on the

default certificate nickname name for glassfish servers.

Once the keystore was created, below in Figure 9, a self

signed certificate was then created. The Silver Cloud web

service, SilverCloudWS, was then secured by adding

Transport Security to its web service attributes.

Figure 9. Creation of s1as keystore

To validate the SSL protection, Calomel SSL Validation

0.52 was installed on the browser. The Firefox add-on

measures the security grade of the SSl connection,

grading it on colour, from green(Strong) to red(Weak). It

also provides a detailed summary of the SSL connection,

the results of which can be seen below in Figure 10. For

testing purposes self signed certificates were used, but in

production, a certificate authority(CA), will be used.

14. UNVALIDATED REDIRECTS AND

FORWARDS

The last vulnerability in OWASP’s top 10 is invalidated

redirects and forwards. To test this vulnerability, Chris

Weber’s Watcher (Weber, 2011), a passive web security

scanner, was used. This tool is part of Fiddler. It is a very

useful for testing cloud applications as it does not run the

risk of damaging shared infrastructure as it a passive tool.

When testing the application, Watcher was running in the

background checking for vulnerabilities. The first high

risk vulnerability can be seen in Figure 11 below.

The vulnerability was the response of a URL that had a

exposed ViewState value that contained no cryptographic

protection. This leaves the JavaServer Faces ViewState

vulnerable to tampering. To resolve the problem, the

following context parameters were added to web.xml

(Apache, 2012).

Figure 10. Calomel SSL Validation Result

Figure 11. Fiddler test results from localhost



<context-param>

<param-

name>org.apache.myfaces.USE_ENCRYPTION</param-

name>

<param-value>true</param-value>

</context-param>



<context-param>

<param-

name>org.apache.myfaces.ALGORITHM</param-

name>

<param-value>AES</param-value>

</context-param>



<context-param>

<param-

name>org.apache.myfaces.ALGORITHM.PARAMETERS

</param-name>

<param-value>ECB/PKCS5Padding</param-value>

</context-param>

The above code simply sets the use encryption value to

true, defines AES as the encryption algorithm to be used

and defines the padding for the algorithm.

ECB/PKCS5Padding is actually the default value used.

As the server did not set use encryption to true, which it

should by default, the padding for the algorithm was

defines as well. The secret key value is a random 24

numeric character string encoded to Base64. As can be

seen in Figure 12 below, the ViewState value is

encrypted.

Figure 12. The ViewState value from a request

This seemed to resolve the problem as the vulnerability

did not reappear. AsWatcher is a passive tool, it would

always be running in the background as it has no impact

on the server or application. Watcher will also be

passively analysis when the application is hosted on the

cloud.

15. CLOUD APPLICATION SECURITY

TESTING

Once all application testing was completed, the next task

was deploying the application to Windows Azure. For the

purposes of testing, the application was deployed to

staging server. There are no real differences between

staging and production s both servers are set up the same.

The only difference is the DNS name. The tests were

executed in the exact same format as local host testing.

16. INJECTION, XSS AND UNVALIDATED

REDIRECTS AND FORWARDS

Injection was re run with the same results. Hosting on

Azure server did not have any impact on the results. There

was a slight decrease in false positives relating to

JavaServer Faces as the version was upgraded from 1.2 to

2.0. The only issue found testing XSS on local machine

was the HTTP flag. Hosting on Azure did not introduce

any new XSS vulnerabilities. The watcher tool that was

used to test Unvalidated Redirects and Forwards did not

return any new vulnerabilities.

17. INSECURE DIRECT OBJECT

REFERENCES

Adding encryption to the SOAP messages provided added

security. However during deployment to Microsoft Azure,

configuration problems resulted in the server environment

being changed from glassfish to tomcat. Unfortunately,

encryption was unable to be implemented on the new

server. This did not introduce any new insecure direct

object references, however it resulted in soap messages

being sent in plain text once more. A change was

implemented in the code, where a unique String is now

sent with every message request. This prevents users

invoking the web services since by getting the end point

that is running in azure.



If a user called the web service to download a file, they

could guess a random user id and file id and see if any

results are returned. They must now send a string called

verifier. If verifier value is correct, the request is

processed. This is not as good as sending web services

with digital certificates and encrypted body text. With

more time to examine encrypting techniques in tomcat, a

solution along with the verfier would greatly secure the

web services.

18. SECURITY MISCONFIGURATION

When deploying the application to Azure, issues

regarding compatibility resulted in the server being

changed from glassfish to tomcat. No new security

misconfiguration appeared but certainly would be

questioning the capability issues that deploying to the

cloud created. When the issues was raised with a member

of Azure support team, they did not have a solution for

the problem. The IDE also had to be changed to a

different version of eclipse to support the azure plug in.

Changing the application configuration could introduce

new security vulnerabilities.

19. CONCLUSION

The results show that the application does not develop

vulnerabilities in the cloud. Any vulnerabilities before a

application is deployed would remain. With Azure, the

server is packed up along with the application. Any

configurations made to the server will remain the same

when hosted on the cloud. This ensured that changes as a

result of the application security testing remained

implemented once hosted which resulted on test results

remaining the same both on local host and Azure.

Obviously this puts reasonable doubt over any cloud

insecurities. However, a new vulnerability was

discovered. As mentioned, the server and IDE had to be

changed when the application was deployed to the cloud.

Apart from the time and money it could cost to change the

application to be more capable, what effect could this

have on the security of the application. Changing a project

could introduce new bugs and vulnerabilities. Secure

measures implemented may not work with a different

version.

REFERENCES

[1] Microsoft Service Agreement, August 2010. URL

http://explore.live.com/microsoft-service-agreement?

mkt=en-gb.

[2] Security of Cloud Computing Providers Study.

Technical report, Ponemon Institute LLC, April

2011.

[3] Defined Categories Of Service. White paper, Cloud

Security Alliance, 2011. URL

https://cloudsecurityalliance.org/wp-content/uploads/

2011/09/SecaaS_V1_0.pdf.

[4] Burp Suite, 2011. URL

http://portswigger.net/burp/download.html.

[5] Cloud Security Alliance. CCSK Early Adopters,

March 2012. URL https://cloudsecurityalliance.

org/education/certificate-of-cloud-security-knowledg

e/ccsk-early-adopters/.

[6] Anon. Federal Risk and Authorization Management

Program(FedRAMP), 2011. URL http://www.cio.

gov/modules/fedramp/demo.cfm.

[7] An Official Website of the United States

Governement. Apache. Apache MyFaces Web

Config, April 2012. URL http://myfaces.apache

.org/core20/myfaces-impl/webconfig.html.

[8] Jacob Aron. Beware of the botcloud. New Scientist,

pages 24–24, June 2011.

[9] Warwick Ashford. Untitled. Computer Weekly, page

28, September 2010.

[10] Warwick Ashford. Securing the cloud. Computer

Weekly, pages 16–20, April 2011.

[11] Stephen Baker. Google and the wisdom of the clouds,

December 2007. URL http://www.msnbc.msn

.com/id/22261846/.

[12] Jayant Baliga, Robert W. A. Ayre, Kerry Hinton, and

Rodney S. Tucker. Green Cloud Computing:

Balancing Energy in Processing, Storage, and

Transport. Proceedings of the IEEE, pages 149–167,

January 2011. ISSN : 0018-9219.

[13] Jon Brodkin. Gartner: Seven cloud-computing

security risks, July 2008. URL http://www.

networkworld.com/news/2008/070208-cloud.html.

[14] Bill Claybrook. The Bumpy Road to Private Clouds.

Computer World, pages 18–23, December 2010.

[15] CSA. Security Guidance for Critical Areas of Focus

in Cloud Computing V3.0. Technical report, Cloud

Security Alliance, November 2011.



[16] John Edwards. Cutting Through the fog of Cloud

Security. Computerworld, pages 26–29, February

2009.

[17] Paul Engle. An improving cloud. Industrial Engineer:

IE, page 20, 2011. ISSN:1542894X.

[18] Simon L. Garfinkel. The Cloud Imperative. MIT,

October 2011. URL http://www.technologyreview

.com/business/38710/.

[19] Craig Gentry. Computing Arbitrary Functions of

Encrypted Data. Communications of the ACM, pages

97–105, March 2010.

[20] Andy Greenberg. Spurned by yahoo!, hacker puts

account-stealing worm up for sale. Forbes.com, pages

38–38, May 2011.

[21] John Kennedy. Security is major inhibitor preventing

cloud adoption by firms, December 2011. URL

http://www.siliconrepublic.com/cloud/item/25004-

security-is-major-inhibitor.

[22] Mitja Kolsek. Session Fixation Vulnerability in Web-

based Applications, February 2007. URL

http://www.acrossecurity.com/papers/session_fixatio

n.pdf.

[23] Bruce Levinson. FedRAMP: Critical to Cost-

Effective Cloud Computing Cybersecurity, March

2011. URL http://www.circleid.com/posts/20110330

_fedramp_critical_to_cost_effective_cloud_computin

g_cybersecurity/.

[24] V. Benjamin Livshits and Monica S. Lam. Finding

Security Vulnerabilites in Java Applications with

Static Analysis. 2005. URL http://suif.stanford.

edu/papers/usenixsec05.pdf.

[25] Mark McCourt. Cloud computing. SDM: Security

Distributing & Marketing;, 42:62–70, February 2012.

[26] Gary Mcgraw and Edward Felten. Twelve rules for

developing more secure Java code, December 1998.

URL http://www.javaworld.com/javaworld/jw-12-

1998/jw-12-securityrules.html?

[27] Russ McRee. Owasp top 10 tools and tactics. Infosec

Institute, March 2011. URL http://resources.

infosecinstitute.com/owasp-top-10-tools-and-tactics/.

[28] Peter Mell. The NIST Definition of Cloud

Computing, January 2011. URL http://csrc.nist.

gov/publications/nistpubs/800-145/SP800-145.pdf.

ISSN: 10476210.

[29] Microsoft. Microsoft Security Intelligence Report.

Technical report, 2011. Volume 11.

[30] Rena Pacella. Hacking the Cloud. Popular Science,

pages 68–71, April 2011.

[31] Scott Paquette, Paul T. Jaeger, and Susan C. Wilson.

Identifying the security risks associated with

governmental use of cloud computing. Government

Information Quarterly, pages 245–253, July 2010.

[32] David Rosenbaum. Cloud Control. CFO, pages 31–

34, September 2011.

[33] Chris Talbot. The State of Cloud Computing: Getting

Real in 2012. Channel Insider, pages 1–4, January

2012.

[34] Steve Van Till. The Cloud: Secure Enough for

Security. SDM: Security Distributing & Marketing,

pages 107–110, July 2011.

[35] Paul Tuckey. Url Rewrite Filter, 2005. URL

http://www.tuckey.org/urlrewrite/.

[36] Chris Weber. Watcher: Web security testing tool and

passive vulnerability scanner, October 2011. URL

http://websecuritytool.codeplex.com/.

[37] Jeff Williams and Dave Wichers et al. HttpOnly. the

Open Web Application Security Project, 2010a. URL

https://www.owasp.org/index.php/HttpOnly.

[38] Jeff Williams and Dave Wichers et al. Top 10 2010,

2010b. URL https://www.owasp.org/index.php/

Top_10_2010.

[39] Jeff Williams and Dave Wichers et al. Top 10 2010-

A3-Broken Authentication and Session Management,

2010c. URL https://www.owasp.org/index.php/Top

_10_2010-A3.

journal of engineering the capabilities and vulnerabilities of

Documents