MODULE 26
Application Hardening
In the earlier days of security, most of the focus was on securing networks. As time passed, the focus turned to securing operating systems. Eventually, as more vulnerabilities were discovered in applications (both traditional client/server and web applications), more of an emphasis was placed on application security. Application security not only means hardening an application, much like you would a network device, operating system, or host, but it also means considering security throughout the software design and development processes. Secure coding and development has become an important issue in the information security world, as this module will demonstrate.
Securing Applications
Securing applications has many different facets. Again, like the process used to harden a network or host, hardening an application takes place on many levels. Some hardening techniques correspond to the same vulnerability issues found on networks and hosts—use of non-secure protocols, lack of encryption and authentication, and so on. Other weaknesses that must be examined when looking at software applications include communications between applications, malicious user input, error handling, bounds checking, and a plethora of other issues. In this module, we’ll take a look at some of these issues, continuing our discussion from the past two modules on application security. We will examine a few of the concepts involved with application security and hardening, such as secure coding, patching, preventing certain web-based application attacks, and others.
Application Security Controls and Techniques
Several techniques and methods are used to secure and harden applications; some of these occur during development of the application, and some are implemented both during and after development, well into the implementation of the software on the network. Methods used during development include a secure software development model, secure coding techniques, and vulnerability testing. The hardening techniques used after implementation include application hardening and patching, as well as developing a secure baseline of the software as it is implemented and operational. We’ll look at all of these methods throughout this module.
Secure Coding Concepts
Secure coding is a recent shift in the software development business. Secure coding basically consists of requirements levied on developers to write their software with security in mind, throughout the development, testing, and implementation processes. Secure coding concepts form the baseline of this paradigm, along with software development models. Figure 26-1 illustrates a notional, high-level secure software development model.
Figure 26-1 A notional secure software development model
Several different secure coding concepts are key to this paradigm, including validating input, escaping, and error handling. Additionally, if an application communicates over the network, secure coding practices dictate that the developer include secure authentication and encryption protocol and cryptographic module support. Along this line of consideration, use of standard secure port numbers should be included in the code, and boundary checking should be included, which involves ensuring that variable characteristics such as length, type of data, and so on are restricted to their defined values, so that unexpected data, or data that does not meet the restrictions of the variable or memory space, cannot be accepted.
Application Configuration Baseline
As we discussed in previous modules with regard to host and operating system security, applications should also have a defined, documented baseline configuration. This configuration baseline should consist of the basic functional operational settings needed for the user to use the application properly. The baseline should also include a fully patched, securely configured set of baseline configuration settings. This configuration baseline may change occasionally as updates and patches are applied, as new users are added to the application, and at other times. The application should be tested whenever it is changed from the baseline, and once the changes have been confirmed as both functional and secure, they can be added to the new baseline.
Application Patch Management
Just as with network devices in operating systems, applications require patches because new vulnerabilities are discovered every day, flaws are discovered in software, and hackers discover previously unknown exploits to compromise applications. Patches help take care of these issues and fix functional problems as well. A patch management program is necessary for keeping an application up-to-date with the latest security issues. Patch management can be performed in an automated fashion or manually. As with patch management with other production systems, patches for applications should be thoroughly tested in a nonproduction environment before applying them to the production or operational applications used by the organization. This will help prevent issues that can stem from security patches that break functionality, or, even worse, to avoid introducing security issues into the infrastructure.
Application Hardening
Application hardening uses some of the same measures taken to harden network devices and operating systems. Application hardening involves locking down the ports, protocols, and services used by applications to communicate with other applications and systems on the network. It also involves configuring user privileges appropriately. Most applications either have built-in user account databases that contain the accounts of authorized users as well as their associated permissions, or they use network- or operating system-based account databases. Regardless of where the user account authentication comes from, user account access control within the application must be considered as well. The principle of least privilege should be applied within all applications, meaning that a limited number of users will have administrative privileges for the application. Most users should have very limited privileges, usually only what they need to perform their job function. Additionally, patch and security configuration management is important in application hardening.
Application-Aware Security Devices
In earlier modules, we discussed network devices and how they filter traffic throughout the network based upon different criteria. These criteria normally include ports, protocols, services, source and destination addresses, and so on. These characteristics are considered metadata, or data about the traffic itself. Most of these methods, however, don’t consider the content of the traffic. Based upon the rules of most firewalls and routers, a particular piece of traffic may be acceptable because it’s an allowed protocol or it uses an allowed port number. Even so, the content of the traffic may be malicious in nature. That’s where application-aware devices come into play.
Many modern, advanced network devices are able to do deep-content inspection on application traffic. This includes close examination of HTTP traffic and its contents, as well as other typical Internet protocols, for example. These application-aware devices can also filter traffic based upon other content-based characteristics, to include file attachments, file extensions, and embedded metadata that indicates what type of application produced or uses the content of the traffic. Security devices that are application-aware include firewalls, intrusion protection and detection systems, proxies, and web security gateways. Using application-aware security devices on the network helps mitigate some issues that may be incurred by using non-secure or potentially malicious software applications. Note that not all security devices support application-level content filtering; for example, a typical network perimeter firewall may not support web content filtering, unless this function is included in its feature set. A web-application firewall, however, is specifically configured for this type of filtering.
Fuzzing
Fuzzing is a vulnerability testing technique that applies to software and applications. It is used to test input validation, bounds checking, error handling, and other potential issues with applications. Some software packages are specifically geared toward fuzzing, but usually they are used under the supervision and knowledge of experienced penetration testers, who are also experienced, security-minded programmers. Fuzzing involves entering all sorts of random data into an application, throwing everything and anything at the application to gauge its reaction, including how it handles errors with unexpected data. Many different vulnerabilities can be discovered during fuzzing, including buffer overflow conditions, input validation, and so on.
Application-Specific Attack Prevention
Now that we’ve talked about general methods and techniques for securing and hardening applications, let’s take a moment to discuss how to prevent some application-specific types of attacks. We’ll extend our discussions from the past two modules and cover methods to counter some specific types of attacks, including cross-site scripting (XSS) and cross-site request forgery (XSRF) attacks.
NoSQL Databases vs. SQL Databases
In the previous module, we discussed SQL injection and the dangers it presents to web applications and the servers hosting them. One consideration for database security, however, is the use of SQL-based databases, versus what are referred to as NoSQL databases. NoSQL databases are sometimes used in cloud computing implementations and big data models. They’re often used for performance purposes, since some of their operations execute much more quickly than a typical corresponding relational database operation might. NoSQL databases, however, are not as mature as SQL databases; they are not standardized the way SQL-based models are, they don’t have common interfaces from implementation to implementation, and they are not considered as secure as SQL models. They often rely on other security measures, either through the applications that access them or file-level security mechanisms on the hosting machine. While NoSQL databases may seem appealing due to the ease of implementation and performance, security should be a careful consideration in their use versus an implementation of more secure SQL database programs.
Client-side vs. Server-side Validation
Validation is very important, because it can prevent all manner of application attacks. There are generally two approaches to input validation: client-side validation and server-side validation. Client-side validation takes the approach that input can be validated through code on the client side of the connection, usually through the browser, using any code that the server sends to the client making up the form the client receives. The client could ensure that a user doesn’t input text in a form field that requires numerical values, for example. This is actually quite efficient and enhances performance. However, the server and application can’t always trust that the client’s browser will effectively perform input validation on the client side. Because of this, server-side validation is considered more effective and secure. Server-side validation allows the user to input data into a form field, for example, and then the server receives the data and validates it before it has been processed by the web application. Server-side validation is not as performance-efficient as client-side validation, but it is more secure, simply because it ensures that no matter how the client browser is set up or how secure the client is, validation takes place. The server does not have to trust input coming from the client; it assumes all input is invalid until checked.
Cross-Site Scripting Prevention
Preventing an XSS attack requires some work on the part of the web application developer. One way to prevent the attack is to develop XSS filters, which essentially send all of the potentially malicious scripts and data from user input into filters that check for the different types of XSS attacks. This can be problematic, simply because there are so many different ways to implement this type of attack. Still, filters can be used to eliminate a majority of the more common methods of attack. Another way to prevent an XSS attack is to write the web application code such that all input data from user forms is considered as data, rather than as executable code. The functions used to implement this measure are language- and platform-dependent, but this should be an important part of the organization’s secure coding standards. You can use application fuzzing or vulnerability testing to discover if your web applications are vulnerable to XSS and other attacks. Figure 26-2 shows an example of a web vulnerability scanner detecting XSS vulnerabilities on a test web site.
Figure 26-2 Acunetix vulnerability scanner results from a test scan
Cross-Site Request Forgery (XSRF) Prevention
Cross-site request forgery (XSRF) attacks attempt to steal authentication information from session cookies during the user’s current browsing session. The user is normally tricked into visiting a malicious web site through redirection or phishing, and the malicious web site executes code that attempts to steal the authentication information and impersonate the user. Note that this attack requires that the user already be authenticated to the secure site, so that their session credentials are stored in the browser. To prevent this type of attack, you can do a couple of things. First, the use of a cryptographically generated token for the user session prevents malicious web sites from gaining the user’s authentication credentials, since the token can be used for only that particular session with the secure web site and can’t be reused. Additionally, the malicious web site would not have the challenge-response information needed to use or regenerate the token. Another method is to encourage users to log out of secure web sites when their sessions are completed, so the session information isn’t saved on the computer. Also, it’s not a good idea to have the browser save authentication information (such as usernames and passwords) for any site.
Module 26 Questions and Answers
Questions
1. Which of the following are valid considerations in secure coding practices? (Choose two.)
A. Error handling
B. Input validation checking
C. Host OS authentication
D. Network device encryption algorithm negotiation
2. Which of the following is an important aspect of standardizing the final operational, secure build of an application?
A. Input validation
B. Boundary checking
C. Baselining
D. Secure coding
3. Which of the following should be accomplished before installing a patch on a production application?
A. Patches should be tested on applications in a nonproduction environment.
B. End-users should be asked for approval.
C. Encryption support for network-based applications should be checked.
D. Application fuzzing should occur.
4. Your manager wants you to grant administrative-level permissions for a particular application to a group of users in the organization. This application is network-enabled and processes very sensitive data. The users in the group are not all technically knowledgeable, and you are often called to clean malware infections from their systems. When you explain to the manager why this is not a good security practice, which of the following alternatives could you give her? (Choose two.)
A. Assign administrative permissions to the application only to a few needed technically knowledgeable users.
B. Assign all users administrative permissions to the application.
C. Assign the manager administrative permissions to the application.
D. Assign all non-technical users only the permissions needed to perform their job functions in the application.
5. Which of the following does an application-aware security device focus on when examining network traffic?
A. Protocol
B. Port
C. Source IP address
D. Content
6. Which of the following is a vulnerability testing method that is specifically used on applications?
A. Humping
B. Fuzzing
C. Poking
D. Jabbing
7. All of the following would be considerations in implementing a NoSQL database, except:
A. Maturity level of NoSQL database systems
B. Lack of common interfaces with NoSQL systems
C. Robust security measures built into NoSQL systems
D. Database performance
8. Which of the following would be considered a more secure way of input validation?
A. Add-on validation
B. Server-side validation
C. Client-side validation
D. Browser validation
9. Which of the following are common ways to prevent XSS attacks? (Choose two.)
A. Restrict the creation and use of session cookies during secure sessions.
B. Encrypt all browser sessions.
C. All input data from user forms is processed as data, rather than as executable code.
D. Use XSS filters to check for different types of attacks.
10. Which of the following attacks is an attempt to steal authentication information from session cookies during the user’s current browsing session?
A. Cross-site request forgery
B. SQL injection
C. NoSQL injection
D. Cross-site scripting
Answers
1. A, B. Both error handling and input validation are valid considerations in secure coding practices.
2. C. Baselining is the process of standardizing the final operational, secure build of an application.
3. A. Patches should be tested on applications in a nonproduction environment before installing them in production.
4. A, D. In this scenario, you do not want to assign all users administrative-level permissions, nor does the manager need those permissions. You should consider assigning a few select technically knowledgeable users appropriate administrative-level permissions to assist with administering the application, and assign all other users, particularly the non-technical ones, only the permissions needed to perform their authorized job functions, so that the risk of exposing sensitive data to the network or through a malware infection is reduced.
5. D. An application-aware security device focuses on traffic content when examining network traffic.
6. B. Fuzzing is a vulnerability testing method that is specifically used on applications.
7. C. Robust security measures are not built into NoSQL systems; that is a significant difference between them and traditional SQL-based systems.
8. B. Server-side validation would be considered a more secure way of input validation.
9. C, D. Writing application code that treats all input as text versus executable code and using XSS filters are common ways to prevent XSS attacks.
10. A. Cross-site request forgery is an attempt to steal authentication information from session cookies during the user’s current browsing session.