Applications can allow computers to perform an immense number of tasks, but they can also open up a host to unwanted exploitation and vulnerability. If an application has access to edit locally stored files, but is vulnerable to unauthorized control, your locally stored files become vulnerable to unauthorized control. In this section, we will be looking at a number of security practices and principles that can enhance the security of applications. This section will cover the following topics:
- Fuzzing
- Secure coding concepts
- Cross-site scripting (XSS) prevention
- Cross-site request forgery (XSRF) prevention
- Application configuration baseline (proper settings)
- Application hardening
- Application patch management
Fuzzing
Fuzzing is the practice of sending a large collection of unexpected inputs to an application in hopes that the application will sometimes react in a manner the program’s creators did not intend. This may result in a simple denial of service, access to unexpected data, or even access to the computer on which the application is hosted.
Using an application to generate an extremely large range of inputs (i.e., a fuzzing engine) is the most common way fuzzing is used to test an application. It is impractical to generate these inputs manually, but the use of the fuzzing engine allows a large number of inputs to be tested quickly and records the responses of the application. Fuzzing allows attackers to find vulnerabilities in the way closed-source applications process inputs. If the developer has not designed the application in such a way as to validate or process all possible inputs, fuzzing is one way to discover any exploits.
Secure Coding Concepts
When it comes to making a securely coded application, it is much more difficult to transform an already written insecure program into a secure one than to program with security in mind from the beginning. Security is not something added on later, but, rather, it is an important consideration at every step in development.
One basic secure coding concept is error and exception handling, ensuring that when a program cannot perform a given task, it fails gracefully and securely. Rather than a runtime error being displayed to the user, the application should generally catch the error and display or log error information chosen by the developer, rather than a default error message from the OS or scripting language. A mishandled exception may allow an attacker an opportunity to exploit your code.
Another basic secure coding concept is input validation, allowing only inputs that match a certain format or range. A first name field, for instance, would not allow special characters such as a semicolon or the equals sign to limit the availability of scripting attacks. Secure coding concepts assist in hardening applications against attacks, which is a concept discussed later in this section.
Cross-site Scripting (XSS) Prevention
Oftentimes, a browser will execute scripts that are presented to it. Whenever this is done maliciously, it is considered a cross-site scripting (XSS) attack. Any application that accepts inputs from a web interface should validate the inputs to protect against the possibility of an attacker injecting malicious scripts, especially if one user’s input will be presented to other users. Input validation can protect your site from becoming a launch pad for XSS attacks.
Cross-site Request Forgery (XSRF) Prevention
In a cross-site request forgery (XSRF) attack, the attacker impersonates a different authenticated user and uses their authentication to access information the attacker should not have access to. To protect against XSRF attacks, the authentication process should be encrypted and authenticated sessions should be terminated regularly to prevent session hijacking.
Application Configuration Baseline (Proper Settings)
To ensure basic application security, your organization must set a basic standard for the use of applications, or an application configuration baseline. Does your organization require the use of a certain browser, or the use of a certain version of that browser? Do macros and scripting need to be disabled, or is the tradeoff in usability versus security not worth it? The application baseline is the established minimum for applications in your environment. Every host in your environment should meet this baseline.
Application Hardening
Application hardening is the process by which applications can be made more secure. Application hardening includes code reviews, the application of a security baseline, and application configuration settings. A hardened application will apply a number of principles and practices, such as changing default authentication information, allowing the least necessary privileges for the application to function, and limiting the attack area of the application by disabling unnecessary application components. Another major change made to ensure application hardening is changing default passwords on any applications, such as databases, or any appliances, such as routers, as default usernames and passwords are easily found on the Internet and can be used to gain access.
Any and all changes made to an application to make the application more difficult to attack are examples of application hardening, whether those changes are made in the design and development of an application or made to the configuration of an already deployed application.
Application Patch Management
Once a security baseline has been established, it will need to be constantly revised to take into account new application versions, which may add new features or fixes for security vulnerabilities. Many applications can be upgraded on an individual basis, but for large environments, it may not be practical for updates to be made on a computer-by-computer basis.
When new application patches or versions are released, an administrator should determine whether the patch would help or hinder normal operations, and update the applications and application baseline if necessary. Not every new version will increase security or have features worth upgrading to. The new version can be rolled out to the hosts that want new features or, if the application baseline is updated, to all hosts.