View
0
Download
0
Category
Preview:
Citation preview
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
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1063
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.
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1064
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
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1065
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
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1066
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
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1067
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
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1068
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
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1069
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,
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1070
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
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1071
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
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1072
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
<!-- enable encryption -->
<context-param>
<param-
name>org.apache.myfaces.USE_ENCRYPTION</param-
name>
<param-value>true</param-value>
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1073
</context-param>
<!-- Defines the secret (Base64 encoded) used to initialize
the secret key for <context-param>
<param-name>org.apache.myfaces.SECRET</param-
name>
<param-
value>NDU5NzQ2NTQ1NjQ1NDE1NTE1NDE1NDU2</
param-value>
</context-param>
<!-- Defines the algorithm used -->
<context-param>
<param-
name>org.apache.myfaces.ALGORITHM</param-
name>
<param-value>AES</param-value>
</context-param>
<!-- Defines the padding used for the encryption
algorithm -->
<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.
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1074
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.
International Journal of Engineering and Technology (IJET) – Volume 2 No. 6, June, 2012
ISSN: 2049-3444 © 2012 – IJET Publications UK. All rights reserved. 1075
[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.
Recommended