A White Paper : Secure Application Development

Secure Application Development

By
Bob Wiliams
SecureWiFi Networking Consulting

Security and Software

Although software development encompasses a large variety of possible efforts, the need for security is common across all of them. Strong security is a continuous process that arises from comprehensive and well thought-out design and development methods and a continuous analysis throughout the life of the application. Although there is no such concept as guaranteed security, the goal is to create software with security in mind and establish a high degree of protection that makes attack and exploitation difficult and unfeasible.

Here are several guidelines that assist in evaluating and bolstering security of an application or product through the phases of the development cycle. The approach used here differs from common practice. Many sources of information on secure application development focus on the technicalities of the code and implementation, while ignoring other elements of the process. Security in an application comes not only from the code used to create it. It begins with the idea for the application and carries through the design and implementation phases to form a cycle of security analysis. Each of these phases depends on the other to provide the highest level of application security needed and possible. This cycle continues throughout the application’s life-span and should be considered with each new incarnation, enhancement, or modification. Software developers and engineers need to understand methods to design and write code with security in mind, as well as the security issues that might arise from their efforts.

Although this paper focuses primarily on Internet related applications, the concepts here are applicable and important to all forms of software development.

Developers achieve security awareness and thoughtfulness through careful implementation and an aversion to pitfalls. At the end of this paper, you should be able to establish a procedure for secure application development that includes the creation of a security architecture and the ability to examine the design and implementation for relevant security issues.

What is a Secure Application?

A secure application emphasizes thoughtful analysis, diligent design and a focus on implementation. It’s developers consider the security issues of similar applications and analyze innovations for new risk areas while balancing the level of security required by the users. To make this happen, it is useful to know the effects of insecurity on an application.

Is the Enemy Within Your Own Code?

Common attacks such as DoS, buffer overflows, and race conditions can plague applications with poor methods of input validation and data protection. This is a brief overview of common vulnerabilities.

Configuration Issues

Security problems with configuration of an application and the environment in which it runs are very common. Applications often store configuration information in a file or database, write runtime information to other files, and provide multiple services simultaneously. Default configurations can be very dangerous, but are there to help users run the application with the least amount of effort. This leaves the application open to attack.

There is a disadvantage to having every option turned on by default, although it does demonstrate the rich feature set for the user. If a vulnerability is discovered, the user is unknowingly at risk. Think carefully about which options are enabled for regular operation and which should remain disabled.

Race Conditions

As the name indicates, a race condition is a window of opportunity in a running application that enables another process or application to exploit the privilege or functionality of the first. Race conditions can occur when complex or multi-step procedures run, when an application interacts with other processes or resources, or when functionality is poorly organized. When an application is able to escalate it’s system privileges beyond the user privileges, and is unable to relinquish to the user configuration, another service or application that was elevated with it may be compromised and be available to an exploit.

Before creating a function that requires higher privileges or performs complex interactions with components outside of the application, take a moment to organize the functionality and find an efficient way to write code.

Buffer Overflows

The buffer overflow is probably the most notorious and dangerous condition that can occur. Forget the fact that buffer overflow can crash an application and destroy data with invalid inputs. Buffer overflows can be crafted to execute a functionality that was never intended. Processes and services can be accessed as Admin., or Root directly from a buffer overflow condition.

Examine every memory allocation for variable string inputs to make sure that variables have valid parameters with the correct null values.

Data Protection

The scope of data protection is broad. It extends from the internal methods of an application out to the operating system and all of the systems to which it connects. This description focuses on the data protection within an application and the operating system in which it runs. These concepts can be extended to interconnected systems.

It is important to remember that, in most cases, the application and its operating system are using the same physical processor and memory. While this might seem obvious, the security ramifications are often forgotten. A developer cannot assume that the memory used by the application is accessible only by that application. The underlying operating system controls access to memory and therefore has access to all available memory, whether used or unused. If an application is using and manipulating information that should be kept secret, it is vital to protect internal data. Without the proper protection and initialization, exploiting operating system functionality can access this information. Establishing authentication and access control methods can protect data.

Temporary Storage

Temporary storage in files is not itself a vulnerability, but it merits some thought, because it exacerbates the problem of data protection and race conditions.
When using temporary files, check for their existence during initialization of the routine and set permissions to restrict access only to the application. It is also recommended that the file name be randomized to make it hard for an intruder to guess. Finally, remember to delete the temporary file when you are done with it.

Denial of Service Attacks

Denial of service tools are a common form of attack, and can be initiated from the network or on a local system. These attacks exploit a design’s failure to address the negative events in an application. Applications should be developed with an understanding of the functionality they provide and functionality they do not provide. This enables the developer to build safeguards into the application that protect it from denial of service. These attacks come in several flavors, network bandwidth saturation, system resource utilization, and application flaws.
To protect against denial of service attacks, begin to consider where potential vulnerabilities exist in an application. Start early in the design phase and continue the analysis through the completion of the application.

Input and Output Methods

User-supplied or external inputs is the most obvious and prevalent point of entry for attacking an application. Whether data is coming from a network, from a keyboard connected to the system, or from the user environment, the security of the input method demands careful consideration. Application design and implementation must have a defined set of criteria for input. This includes the explicit data type and values that are and are not acceptable, the reaction to unacceptable data, and the path of that data through the application.

Be careful in any application that creates files or accesses the command line based on input. Screen meta-characters out of the input.

Application output can also pose a risk when users blindly write data to files, terminals, or devices. It is equally important to validate output before actually committing the data. The conditions that allow for successful output should be defined and documented to provide a level of assurance within the application that any outbound information is checked.

Criteria for user supplied input should be defined, and associated functionality should be developed to support its validation. This criteria should outline what is and is not acceptable. Any time that externally defined data crosses the boundary of an application or module, it should be validated.

Security Architecture

Security architecture for an application outlines a comprehensive method for the development of reliable and secure applications. It establishes a process and a framework by which the security needs of an application are analyzed, defined and implemented. Here are few components that constitute security architecture.

Components of Security Architecture

Comprehensive security architecture is best achieved through an increasingly more detailed approach that begins from the external viewpoint and progresses through the details of the implementation. Here are some components to organize the information needed for the creation of an application’s security architecture.
1. Risk assessment and response
2. Security requirements
3. Design phase security
4. Implementation phase security

Set the Stage

Assessing the risk of an application requires some diligence on the part of the application designers. The most basic research that identifies the security issues with related applications is a good place to start.
The known vulnerabilities of an existing application can provide hints toward the presence or lack of a security architecture in its design. The vulnerabilities can often be categorized as implementation flaws, design flaws, and functional flaws. Shortcomings in design and function leave holes in the thoroughness of functionality, often creating a security risk.

Consider the Functionality Not Provided

The most basic level of functionality possible is defining what an application does. It is looked at in the most pristine circumstances. It naively assumes that the world is perfect and that nothing bad ever happens when the application is running. All inputs are completely understandable. All network connections are from known clients. All operating systems are sterile and it is what the application expects. Obviously this is not the case in the real world and cannot be expected.
Considering both the positive and negative scenarios for an application’s operation is vital when creating it, The negative view defines the reaction to unknown input, invalid syntax and communications, and anomalous conditions that might occur. The application needs to respond properly to events not expected or defined. Although it is often difficult and infeasible to explicitly handle every known exception, general rules can easily be created to handle undesired events.

Can You Buy Guaranteed Security?

This paper would not be complete without the mention of third-party organizations that provide security software, development kits, and hardware to enhance security of applications. Many of the commercial vendors present their products as providing “guaranteed” security. This is simply untrue; “guaranteed” security is a fallacy. This concept considers security to be a feature or component that can be plugged in for immediate security satisfaction. If only one bit of information is gleaned here, let it be the fact that security is a continuous process.
The inclusion of third-party security technologies should be examined for usefulness and value, given the security requirements that are established for the application.

Security Requirements

In conjunction with identifying related security risks known to a specific applications or genres, developers must assess the security requirements for their own application. This analysis should arrive at a balanced measurement of the level of security required. It does not have to ponder extreme measures. Protecting against known risks and minimizing the number of successful attacks is generally an acceptable level.
To arrive at security requirements, developers can find it useful to concentrate on commonly known risk areas.
1. User authentication and control
2. Data storage of confidential information
3. Security in internal network communications
4. Security of entry points for external applications and operating systems

From these general areas, designers can identify a minimal set of features to analyze. Some risk areas are more important than others, depending on functionality.

Should I Lock It All Down?

It is possible to take application security too far. The performance of the application while it interacts with hardware, operating systems, and networks can be compromised if the complexity of the security measures out-way there usefulness to the original design. This can occur if methods are blindly applied to all components of the application without thought to their requirements. Here is a reasonable starting point to determine a basic security level.

Assessing Authentication and Access Control

Many times user authentication, handled by the operating system, is all that is required.
There are a few classes of application that need to deal with authentication on their own. Embedded applications and distributed Web applications often need some level of user authentication and access control.
Terminal access or network access will determine the most appropriate authentication scheme. The operating system involved should also play a large part in this decision.

Requirements for Data Storage

Data storage reflects the method used to store sensitive information. The correct use of file permissions by the operating system, their location, and encryption, if any, are all part of the data storage arrangement. The nature of the data should always drive the method.

Network and Entry Point Security Requirements

Security of network communication is best addressed by examining the content of the message being sent. Applications that utilize network communication for informational messaging or passing static data may not require anything stronger than the protocol supports. Again, an application that sends sensitive information is likely to warrant the addition of higher security methods. Analysis, Analysis, Analysis.

Network, Application, and System Interaction

Network interaction can be present at several levels. An application can be completely client/server-oriented, for use on remote systems spread across the Internet. The need for security in these applications becomes considerably more complex than a stand alone.
Discern all of the valid dependencies and make a decision from that analysis. The answer to the required security level will probably be somewhere in the middle of two extremes.
The stand alone application may need only non-Internet sockets and IPC mechanisms for related application calls. IP sockets do pose a risk and where possible, they should be avoided for local traffic. Diversion from domain sockets in the UNIX environment is also a consideration when other IPC communication is available.

Operating System Interaction

Interaction with the operating system often creates another level of security issue. The execution of external programs and the use of system and other externally defined calls are common sources of exploitation. Because of their nature, system calls present a high degree of risk when used improperly. Methods to call other applications to run services for the first application are in danger of also calling higher permissions and privileges that once called leave an opportunity for exploit with meta-characters if no validation parameter is in place. The path to Root or Admin will be wide open in this condition. Higher privilege calls should be carefully controlled and returned to minimum as soon a function is completed.

No Security Needed Here

If you chose to ignore security within the application as it is developed and rely on the customer’s operating system or network you are shunning your responsibility to provide secure applications to the public. The security philosophy advocated here is for a strong and comprehensive security ideology that assumes nothing about the components, external to the application. An application should always be as secure as it can be with respect to itself and the external components with which it interacts. The level of follow-through is left to the discretion of the developer and designer.

Identification of Risk

The place to start a risk assessment is to classify possible attacks.
1. Subversion of the application
2. Subversion of the system and external applications
3. Cessation of functionality

The first class of attack has the goal of gaining control of the application or the system it runs on. Failing that, the application can simply crash, or crash the system with it.

Subversion of the system is a wider goal because the compromised application is a conduit to other more useful components for the attacker.

An application can completely cease to function and crash due to attacks. This is a form of denial of service.

Security Response

After the risks and requirements are identified, the response to these issues is the next step. Identification of potential security issues is not very useful without a known path to protect against those risks. The defense methods become a natural part of the design in this phase of development.