Application Security Assessments : Whitepapers : Home

Application
Security Assessments
Advice on
Assessing your Custom Application

Custom applications and their security threats

For many organisations, their internal security
professionals are adept at finding and responding to information about the
latest vulnerabilities and threats to the software employed within
business critical systems under their supervision. There are a great many
security resources available, online and printed, ready to help explain
and address potential vulnerabilities with the most common commercial
software products. However, there exist two problems for those responsible
for the security and integrity of your systems. Firstly, the “hit or miss”
disclosure of vulnerabilities in commercial software, and secondly, how do
you identify or address potential vulnerabilities in the custom (in-house
developed) application that connects and runs atop the commercial
software?

There is very little most organisations can do about
the “hit or miss” disclosure of vulnerabilities inherent to the commercial
software deployed throughout the business. You must rely upon the software
provider to have initiated appropriate quality controls and security
testing, and provide bug-fixes or patches as necessary. Due to various
country specific laws or software agreements, it may actually be illegal
for your organisation to reverse-engineer or otherwise identify security
flaws with the software you have purchased.

In the case of custom (in-house developed)
applications, it is normally possible to conduct a more thorough security
review of the system. There are two paths available to an organisation
wishing to review the security of their application; a code review and an
application assessment. A code review tends towards more of an audit of
coding practices utilised throughout the pre-compiled application, while
an assessment reviews the functionality and resilience of the compiled
application components to real-life threats. While a code review often
initially appears to be more valuable, most organisations soon find to
their amazement that such a review is extremely costly in both time and
effort, and often fails to identify post compilation and deployment
issues. An application assessment focuses on the compiled and installed
elements of the entire system. Attention is made to how the application
components are deployed, communicate or otherwise interact with both the
user and server environments. From past experience, the author has found
that application assessments often represent the best value-for-money when
identifying security threats and resolutions to distributed client-server
applications.

Unfortunately, many organisations will find that they
do not have sufficiently skilled resources available internally to cope
with an application security assessment, and will have to seek security
advice from a security specialist. Not all security organisations or
consultancies can provide application security assessments, but those that
do will normally classify the application or system into one of two
classes; Web and Compiled.

This whitepaper aims to provide an organisation with
enough information to understand the potential threats to your application
beyond classical “ethical hacking” methodologies, and provide helpful
advice on steps that can be taken to limit such security threats.

How hackers execute attacks against custom
applications

Most initial attacks against your systems are likely
to focus upon the systems infrastructure and commercial applications, as
that is where most of the exploit material and methodologies are likely to
work. Depending upon the skills or resources, if your systems are well
secured and up to date with the latest bug-fixes or patches, the attacker
may either resort to social engineering (Why try to crack a password when
you can just call the helpdesk and have it reset?) or focus upon the
manipulation of the vulnerabilities inherent in the application, or
sub-components. Although custom applications can be vulnerable to a number
of attack methodologies. Four attack categories are most prevalent:

Buffer overflow attacks — Buffer overflow
attacks are aimed at application components that take data as an input
and pass it to memory buffers for later use and manipulation. Failure to
adequately check the size of data before passing it into too small a
buffer is commonplace. Attackers may be able to include their own
embedded commands within the oversized data package and thus have their
commands replace existing application code and execute on the system. If
successfully executed, these commands will enable attackers to acquire
privileges that exceed authorised permissions up to, and including,
those of the system administrator — with corresponding control of the
host system. In some circumstances, application components subject to a
buffer overflow may suspend or crash, thus denying users further access
to the service. In other cases such an attack may bring down the host
server and deny access to any services provided by the system.

Race conditions — Under certain
circumstances, when an application requires access to specific files,
variables or data, its programmers may not have correctly implemented
multiple simultaneous accesses and installed the appropriate checks.
This can often lead to an attacker enjoying unintended access to files
or data through trusted and untrusted server application components.

Exploitation of application component
privileges — Server based application components run with specific
group or user permissions, not necessarily with that of the user running
them (such as an anonymous Web user). These application components, if
they suffer additionally from buffer overflows or race conditions, can
be used to increase access and escalate the potential damage to the
system.

Client-side manipulation — To speed up
connectivity and reduce performance loads at the server end, client-side
validation of input and manipulation of data is often required. It is
often a relatively trivial exercise for attackers to bypass this
checking and supply incorrect data or data formats to the server in an
attempt to initiate any of the other three common attack formats or to
reveal both confidential information and server application
functionality. This method is also a popular means of conducting
fraudulent transactions on commerce-enabled sites by changing the values
of available products.

Web-based applications

As Internet businesses have matured, a new category of
application has emerged that enables companies to interact with both
potential and existing clients in this medium. These Web-based
applications — while they rely on conventional corporate technologies such
as database, mail or Web servers — are often subject to design compromises
due to the limits of the medium. Such design compromises, unless carefully
reviewed and analysed, can expose the integrity of the application
components and corporate data to avoidable security risks. In many cases,
in fact, application risks far outweigh the threats to the supporting
environment from traditional hacking techniques.

To make the best use of client-side Internet bandwidth
and to deal with high volumes of simultaneous connections and data
requests, Web-based applications tend to be distributed over multiple
servers using a tiered architecture model. Moreover, they frequently rely
on client-side code to present and manage data. These design
considerations, coupled with the use of scripting-type development
languages and constant changes in authentication and certification
procedures, frequently lead to security flaws in an applications
implementation. Increasingly, Internet-based attacks exploit these
security flaws to compromise sites and gain access to critical systems.

Direct attacks against custom Web applications through
manipulation of their inherent vulnerabilities have become more popular
due to their relative ease and the scope they offer for maintaining
anonymity. Although companies may install various security mechanisms to
strengthen security — firewalls, intrusion detection systems, operating
system hardening procedures, etc. — they seldom expend much effort in
securing and verifying the integrity of applications and coded pages
against external attacks. In these circumstances, simple manipulation of
client code or data, such as the price of goods in an online shopping
basket application or sending corrupt and incorrect data to the server,
can lead to fraudulent transactions or theft of confidential information.

It seems hardly a week goes by without the appearance
of fresh newspaper stories describing how faulty application processes and
input manipulation have led to the loss of confidential data such as
banking details and credit card numbers. In almost all such cases, an
understanding of manipulation techniques combined with rigorous
client-side security testing would have identified the potential failure
points and resulted in a more robust application, thus averting
embarrassing, often dangerous compromises of system and data integrity.

The web-based application security assessment process

The process of assessing the security of a web-based
application, although not technically complex, often relies upon a
multi-facetted approach utilising a variety of technologies and
techniques. Unfortunately, there is currently no quick shrink-wrapped
solution available to automatically and comprehensively assess an
application’s security. Various vendors can supply testing products that
will search for the most basic faults in non-complex
applications/environments and provide advice on better coding practices.
Based upon experience in assessing critical Web-enabled applications,
automated tools should only be used for first-round security testing and
preliminary identification of potential flaws.

Depending on your specific requirements and the type
of web-based application, an application security assessment should
typically consist of the following phases:

Examination of external/client-side visible code
for information that could be used for social engineering purposes or
for information on how an application functions that might be used for a
more focused attack.

Discovery of information on the type of environment
that exists at the server side (eg, embedded SQL queries specific to a
single database version).

Inspection of application validation and bounds
checking — both for accidental and mischievous input. The purpose
of this exercise is to ascertain the limits of correct server responses
when handling unexpected data formats or sizes. This phase involves
buffer overflow attempts to establish system resilience and performance
continuity.

Manipulation of client-side code and locally stored
information such as cookies and session information. Client-side code is
altered to subvert authentication checking and used to establish the
bounds of server reliance on client data fields. URL request information
and GET/PUT requests are altered to achieve unexpected system responses
and access confidential information.

Examination of application-to-application
interaction between system components such as the Web service and
back-end data sources. Attempts are made to reference system components
by impersonating other system functions or sources. Redirection methods
and messaging functions are closely examined.

Discovery of techniques that could be employed by
attackers to escalate their permissions by referencing application
components with higher server-side permissions, or exploitation of race
conditions to identify lax permission or authentication checking.

Attempts to subvert in-transit data between the
client and server system. Examination of data delivery methods and the
likelihood of their subversion or use in a replay-type attack, or other
session orientated attacks, including an analysis of system responses to
such data.

Authentication methods in use are examined for
their robustness and resilience to various subversion techniques.
Attempts are made to bypass authentication processes and/or impersonate
valid logged-in users. Detailed studies of user segregation methods are
undertaken and an analysis of server-side responses to failed attempts
is made.

Overall examination of the application’s deployment
and security configuration from perceived threat models. Advice is given
on secure deployment methodologies for the application type, based upon
market considerations, new vulnerability developments and attack
methodologies.

Compiled applications

Although not as visible or exposed as most web
applications, the security threats to compiled applications are very
similar and often share the same principles of data integrity and
resilience. However, the methodologies and tools necessary for testing the
compiled application and sub-components are quite different. While the
emphasis of a web application assessment is on manipulation of external
client data; for a compiled application, the emphasis is on the
communication methods and data streams between all internal system
components.

The great diversity of compiled applications and their
interaction with other commercial products (e.g. operating systems,
databases, messaging systems and hardware) often means that assessment
methodologies must be tuned to system at hand. For this reason, it is
vital that both your organisation and the assessment supplier fully
understand the scope and reasons for undertaking the security assessment.

General advice on securing custom applications

The Author is often asked for advice on best practices
for securing applications to minimise the developer’s time for correcting
potential flaws that may be discovered during a security assessment.
Several steps should be undertaken, or at least borne in mind, in order to
maximise security and data integrity during the process of building a new
application:

Assume that someone out there will intentionally
try to break your application and may have access to greater resources
than you expended in developing it.

Assume that you will receive erroneous data from
authorised, authenticated users, and develop a way to deal with it.

If you choose to use client-side input validation,
ensure that the input is also validated at the server end.

Avoid complex code and use minimal coding
structures for handling performance related issues.

Be careful with application component privileges.
Always apply the minimum possible permissions needed to carry out any
particular task.

Utilise methods of load limiting to prevent
overloading application components or servers.

Check every return code from system components and
functions to prevent race conditions or malicious input.

Never allow passwords or user specific details to
be passed in plain-text to the client browser or between application
components.

Ensure that confidential system information is not
encoded into documents that could potentially be accessed by a remote
client, either directly or through escalated application component
permissions and calls.

Commonly available libraries or sample code may not
necessarily be secure. Review carefully any third-party code.

Always use full pathnames in system and application
procedure calls to prevent redirection and unexpected use.

Take extreme care with file permissions and access
rights.

Remove all unnecessary material from the hosting
servers and only install services that are required for the
application/system to function.

Remove all comments and unnecessary information
from client-side code.

Distribute application functions between servers
when possible to limit data access from a compromised host.

Use reasonable system timeouts for network reads
and writes to help prevent race conditions being reached and denial of
service attacks.

Ensure you are capable of logging and tracking all
inbound requests for post attack analysis.

Where possible, only use shared resources you have
direct control over. If this is not possible, ensure appropriate checks
for data integrity are made.

Test the application thoroughly!

Get a third party to perform an independent
assessment both of the application’s security and the system’s host
servers before going live.

Conclusion

The security threats and responses to your
infrastructure and commercial software components are commonly understood,
and classical security assessment or “ethical hacking” methodologies are
adept at increasing the security level of your key infrastructure
components. However, custom application code is often untested, and
attackers are now focusing upon these security flaws to compromise system
components or otherwise gain access to confidential data. For these
reasons, organisations should ensure that appropriate security assessments
are carried out on all custom, in-house developed, applications.

Copyright 2001-2007
© Gunter Ollmann