Although vulnerability and security control initiatives for host, mobile, and small form factor devices are very important, let’s face it, applications are the reason why we use computer systems. It is the application that performs the desired work. Yet, applications—popular ones in particular—are increasingly researched and probed for vulnerabilities as well as attacked with application-specific exploits and malware. With more applications in use than ever, we CASP+ professionals must respond with increasing application vulnerability research and iron-clad mitigations.

Initial hacking efforts were aimed at the network and operating system layers in an attempt to gain control over the system and processes that were running. As the network and operating system layers achieved better security, hackers turned their sights to the applications being run on those systems. Application security is the collection of efforts designed to provide protection to the applications used in the enterprise. Whether a standalone application (such as an e-mail or database server) or an application designed around a web server (a web application), commercial software or homegrown, all applications should be considered potential targets.

The basics of security for applications revolve around the issue of software bugs. Errors in software are referred to as “bugs,” and a software bug can have many manifestations—from no issues to catastrophic failure. Many times, the effects are not immediate, but may result in issues in another section of the code or program operation. A bug that can be exploited is referred to as a “software vulnerability.” Vulnerabilities are elements of software that result in an exploitable weakness and can lead to the software performing in a manner not intended by the developer. Not all bugs create vulnerabilities, nor do all vulnerabilities directly result in errors. Often, the error is caused in one section of code but not manifested until an entirely different section is processed.

No matter how you look at it, applications have a plethora of vulnerabilities that require diligence on our part to discover and mitigate before hackers cause irrecoverable harm to the organization. In this chapter, we first take a look at application security design considerations. Afterward, we venture into specific application issues, application sandboxing, secure encrypted enclaves, database activity monitoring, and web application firewalls. Finally, we cover client-side and server-side processing of web content as well as operating system and firmware vulnerabilities.

Application Security Design Considerations

Given the collective desires of managers, IT/security folks, and end users, web applications are quickly becoming the norm. In many ways, they’re more cost-effective, in addition to being easier to plan, design, implement, access, and use than traditional applications. They make working remotely, while using multiple device types, effortless for a growing number of professionals. Web applications are applications hosted on a private or public web server, which is accessed by a user’s web browser application. Web applications may be used for e-commerce, file storage, collaboration, learning management systems (LMSs), content management systems (CMSs), virtual classrooms, and more. This is a highly scalable architecture and is widely used throughout most enterprises. There are many advantages to this scheme, including ease of deployment (because most client devices have built-in web browsers) as well as web-based standards to ensure the secure and consistent delivery of data.

Web applications are not without their risks. There’s a long history of design and programming issues that have led to countless security breaches and data loss. Some of the largest-ever hacker breaches occurred on web servers due to their public visibility and content value. Yet, many of these security issues are avoidable. The use of a secure development life-cycle process coupled with knowledge of the causes and solutions for common errors can go a long way to improve the security of software developed as web applications.

Software development and security should go hand in hand. However, that often doesn’t happen because secure code isn’t produced by security personnel, but rather software developers. Secure application programming should be led by people with an understanding of how to include security as a consideration during the design, default, and deployment phases. The next sections touch on each of these topics.

Secure by Design

Security begins at the design stage. To create a system that is secure by design involves ensuring that the application has considered the threat environment it will be operating within and that it appropriately uses available technology to achieve security. The design of an application can have a huge effect on its attack surface. Attack surface is a term used to describe all the aspects of software accessible to a user, whether by design or not.

Many attributes comprise secure by design. Secure software does not build itself; it is constructed per a design, and a poor design can lead to security-related decisions that provide poor outcomes. When designing software, one must take the environment of use into account. An Internet-facing application has a lot of exposure; therefore, it potentially brings a wide range of threats to an application. Such variety of threats has resulted in threat modeling—a methodology of developing an understanding of and communicating essential information concerning the various threats to a specific piece of software.

Secure by Default

Secure by default refers to the principle that when deployed in a default configuration, security is maintained. Security functionality should not be a user-selectable option requiring user interaction to invoke it. In other words, security should be more proactive than reactive. One method of securing an application by default is in minimizing default program functionality, thus reducing the attack surface of the application. If certain options are not commonly used, disabling them by default reduces the code being invoked during a default installation, and this also reduces the opportunity for attackers to exploit the application.

Secure by default is relative to the typical or default deployment of a product or application. A key aspect in understanding the level of security needed is found by examining the specific threat environment that the software may run in as deployed. The threats to an Internet-facing application are different from those of an application being deployed within an organization. Secure by default also includes an assessment of the functional needs of the application as designed and deployed. Out of the box, Internet Explorer has a different level of functionality on Microsoft Windows Server than it does on a Windows client-based OS. Turning off some functions in the server environment is done to prevent unnecessary elements being exposed to attackers. For example, consider disabling Java scripts, VB scripts, and ActiveX controls. Although these may be important for a client system to enhance a user’s browsing experience, browsing from a server is more restrictive because of the damage an issue could cause.

Secure by Deployment

Software is designed, developed, and tested in an operational vacuum. Once it is deployed, the interaction with other processes, users, and security features creates opportunities to avoid or bypass security controls. Configuring the system so that items such as automatic updates occur seamlessly is important. During installation, software will often create accounts and passwords used as part of the installation process. Deleting, disabling, or renaming these accounts at the conclusion of setup prevents them from being used by unauthorized personnel. Forcing changes of passwords associated with any resident accounts created by the software is another lesson learned.

Specific Application Issues

Applications are a popular target for several reasons. First, they are typically developed by personnel with less resources and training than the major OS and networking vendors. The second reason is that applications also tend to have the information that today’s hackers desire. Hacking takes resources, and today those resources are provided by criminal enterprises and governments. One for stealing information for resale, and the other for stealing information for competitive gain. In both cases, the applications are where the valuable information is accessible. In the past, the information was gained by getting into the network and OS layers, but today those avenues are much harder to exploit. At the same time, the growth of web applications, typically developed with much less emphasis on security, has accelerated, thus providing attackers a fertile bed of opportunity.

Applications are programs that respond to a series of inputs, perform some form of computation, and respond via an output process. Different applications have different input, computation, and output requirements. Speaking of input, input validation is a vital security development concept that should be incorporated into all software. Yet, most applications suffer from some form of input validation risk. Inputs that aren’t validated can allow an adversary to send inputs that force a program outside its design, resulting in unexpected behaviors.

Many common types of vulnerabilities can be mitigated via input validation. From injection attacks (XSS, SQL, or command) to canonicalization attacks, arithmetic attacks, and buffer overflow attacks, input validation offers an application a way to mitigate these forms of attack. One key principle is to consider all input to be malicious until it has been cleaned or proven otherwise. What follows in the upcoming sections are examples of specific application issues, beginning with insecure direct object references. Then we’ll cover cross-site scripting, cross-site request forgery, SQL injection, and several other topics.

Insecure Direct Object References

A direct object reference occurs when an application request refers to the actual name of objects such as files, folders, database, or storage elements. If these object references are left unchecked by the application, attackers can manipulate the requests to gain access to unauthorized resources, or access authorized resources in unauthorized ways. To address this threat, consider implementing access control checks to ensure users are authorized to access the requested object. Also use per-user or per-session indirect object references to prevent hackers from directly accessing unauthorized resources.

Cross-Site Scripting (XSS)

One of the most widespread website attacks stems from cross-site scripting. Cross-site scripting involves attackers discovering and exploiting vulnerabilities on websites in order to inject malicious code—typically JavaScript. Cross-site scripting is abbreviated XSS to distinguish it from cascading style sheets (abbreviated CSS). Attackers take advantage of poor input validation controls on a website to covertly inject the malicious code. Positioned like a landmine, the attacker’s hope is for unsuspecting users to visit the website and run the malicious code. Once the victim’s web browser runs the malicious code, it can lead to stolen cookies, stolen session IDs, session hijacking, malware installation, and bypassed access controls.

The CompTIA Advanced Security Practitioner (CASP+) exam is known for displaying exhibits containing malicious code (XSS, SQL injection, and so on), and you will be tasked with understanding some basics of the attack, such as its type and outcome. Here’s an example of XSS code that will attempt to steal the victim’s cookie:

There are a variety of methods for combating XSS attacks. Comprehensive code review processes and input validation are musts. Also, anti-XSS library functions can be used to handle input from users. Before any user input is processed or used, it should be sanitized by removing scripting elements. Another precaution that can be taken by users is to disable scripts using something like NoScript for Firefox, although this does limit what one can do/experience on the Web. Patching web browsers and servers can mitigate certain XSS vulnerabilities; in addition, these tools can be updated to newer versions.

Cross-Site Request Forgery (CSRF)

In a sense, cross-site request forgery (CSRF) attacks are the reverse of XSS attacks because CSRF takes advantage of the website’s trust of the user’s browser as opposed to the client’s trust in the website (XSS). Also known as session riding, CSRF attacks are the result of malicious code found in e-mails, websites, or instant messages that results in a user’s web browser executing undesired actions on a site to which the user is already authenticated. The term “forgery” is used since the attacker forces the user to run malicious code against the trusted site—unbeknownst to the user—and the site believes the code originates from the user’s browser.

This attack frequently takes advantage of websites that have a “keep me logged in” check box, such as bank and social media sites. The following is an example of this:

1.   The attacker crafts a forged request that will transfer $2,500 from the victim’s bank to the attacker.

2.   The attacker puts the request into a link, which gets delivered to the user via e-mail.

3.   The victim clicks the link, which sends the malicious request to the bank server.

4.   The bank server processes the request to deliver $2,500 from the user’s account to the attacker.

Countermeasures for CSRF can be highly technical and go beyond the scope of the CASP+ exam, but here are some best practices to consider:

•   Use anti-CSRF tokens.

•   Use “same site cookies” if web browsers support them.

•   Require users to click the “log off” button on websites as opposed to just closing the window.

•   Prevent browsers from caching usernames/passwords.

•   Do not include “remember me” or “keep me logged in” buttons on websites.

•   Implement plug-ins such as NoScript.

Clickjacking

Clickjacking is an attack where a user is tricked into clicking something on a web page and then a different operation is performed, as shown in Figure 8-1. The user may think he is clicking a button to perform a specific action, but a hidden form activates a different set of code than expected by the user. A common form of clickjacking is when an attacker creates a transparent page with hidden buttons that overlap the visible buttons. Because the hidden layer is an authentic page, actions are authentic and traced to the user, not the attacker. Client-side browser extensions such as NoScript and Ghostery can be used to detect clickjacking and other exploits.

Figure 8-1    Clickjacking

Clickjacking can and should be addressed from the site owner’s perspective. It is possible to take a couple actions that can reduce the possibility of clickjacking—or at least make clickjacking more difficult to create. The first is the use of the X-FRAME-OPTIONS header, which controls whether or not a site can be embedded within a frame. Using the DENY option prevents the content from appearing in a frame; the SAMEORIGIN option only allows a site to be framed by same-origin web pages. A less effective approach is the use of JavaScript frame-busting methods, although attackers can disable these by setting SECURITY=RESTRICTED on their iframe to disable the JavaScript frame-busting defense.

Session Management

The Hypertext Transfer Protocol (HTTP) is stateless by design. Each HTTP GET or POST request is in the form of a new TCP connection, and may go to a different web server in a web farm environment. If the user experience from page to page requires information transfer, this must be done either through a session ID or other set of state information passed with the requests from the client. This is referred to as session management, which is typically performed through the use of cookies.

There are several security aspects to session management. An unauthorized eavesdropper could use session information to perform a session hijack. Although there are many techniques for session hijacking, here are a few high-level hijacking concepts to be aware of:

•   Session fixation attack   The attacker lures the user into authentication with a known planted session ID and then hijacks the session afterward. The attacker may initiate this by providing the user with a link containing a valid session ID that the user then clicks, which will “fixate” the user with the session ID. The session ID may be baked into the URL, cookie, or a hidden form field.

•   Session prediction attack   The attacker “predicts” session IDs through guessing or brute-force techniques.

•   Session ID sniffing   The attacker sniffs network traffic that contains session IDs.

•   TCP segment hijacking   The attacker sniffs network traffic to establish and predict future patterns regarding TCP SYN and ACK flags, in addition to sequence numbers and acknowledge numbers. This is considered “network-level” hijacking, as opposed to the prior three methods, which are commonly known as “application-level” hijacking.

To protect against session hijacking, consider implementing the following security recommendations:

•   Implement the logout feature on websites to ensure sessions are expired.

•   Generate session IDs after login and accept session IDs generated by the server only.

•   Use secure security protocols such as SSL/TLS, SSH, Kerberos, and IPSec.

•   Use different username/passwords for different accounts.

•   Use longer session IDs than the ones generated by previous algorithms.

•   Provide end-user security training.

•   Employ anti-malware scans.

•   Engage in patch management.

•   Employ session timeouts.

•   Force reauthentication after a certain period of time.

Input Validation

Input validation is possibly the most powerful security tool a developer can wield. A wide range of attacks take advantage of the fact that users get to provide input to a computer program and they don’t necessarily have to provide the input the program is asking for. Buffer overflows have been one of the most storied vulnerabilities found in software. Buffer overflows are a prime example of the effect of not validating input before use.

Input validation can be described in a simple way. Developers should ensure that all input is proper in form and length before processing or using it in any fashion. Also, all input should be considered malicious until proven otherwise. Although seemingly simple, in practice this can be difficult to do. Parsers and other processes can intervene, affecting an application’s ability with respect to detecting input issues.

Several specific issues need to be addressed as part of input validation. The simplest is data length. Data input occurs for a purpose, and the application should have an idea of how long the data input should be. Validating the input length is important—if it is too long, it can overwrite the buffer and result in failure. After screening for length, the more difficult task of screening for content begins.

Content screening can take several forms. There is whitelist screening, where only acceptable items are passed. There is blacklist screening, where disallowed objects are removed or rejected. The problem with whitelist screening is that this form of screening is better performed with a checklist-type user interface and requires user interaction as applications change. Blacklist screening is difficult in many cases because of Unicode and other forms of encoding, canonicalization, and multiple encoding to obfuscate what should be excluded. Verifying the format of an item using tools such as regular expressions can be used for some items (e-mail, SSNs, phone numbers, and so no). Numbers can be checked with check digits, or limit checks (greater or less than a specific value). Content checks (such as date ranges for birthdays) and consistency checks (for example, making sure the ZIP code and state match) can be performed to screen data.

In the long term, forms of whitelist screening will have to be developed because the list of desired applications is finite, whereas the list of all possible undesired applications could be considered near infinite when you add in the issues of obfuscation. The challenge is in developing a methodology for whitelisting that automates the process and does not inconvenience the end user.

SQL Injection

SQL injection is an injection attack designed to attack the database associated with a web application. There can be several different databases, each with important information. A user database with user access information can be harvested to obtain system credentials. An application database can be harvested to obtain application information. The objective of a SQL injection could also be destructive, such as deleting records or dropping tables. Here’s an example of a SQL injection command dropping a table called “users”:

SELECT firstName, lastName FROM users WHERE userID='x'; DROP TABLE users;--';

This is a devastating SQL injection command because the table being dropped is the users table!

SQL injection is one of the most common attack vectors used today. It can provide direct access to the database, which can allow even greater plundering than application-level access. The vast majority of SQL injection attacks occur because of a combination of poor input validation and inline SQL calls. Programs will build a specific query based on user input and pass that query on to the database.

Several methods can be used to access data from a database via an application program. The easiest to design and program is a query string with user input that is passed over a database connection and the records returned. The problem with this method is that the user input can completely alter the SQL query, and this can be difficult to detect or remove without significant input validation. More secure is the method of stored procedures, but this requires additional programming experience and more comprehensive design effort.

Defending against SQL injection requires a variety of countermeasures, including the following:

•   Implementing input validation

•   Disabling commands like xp_cmdshell

•   Suppressing error messages or customizing error messages

•   Ensuring database accounts use least privileges

•   Monitoring SQL statements to identify any statements that look malicious

•   Using parameterized queries

•   Escaping user-supplied input

Improper Error and Exception Handling

Errors are a natural part of software. Not all contingencies can be foreseen, and error handling is an essential element in secure coding. All exceptions and errors should be trapped and handled. In the process of handling the error, if information is passed back to the user, it should meet several criteria. First, the information should be clear and actionable by the end user. Cryptic messages, or generic “contact your administrator” messages, do nothing but frustrate the user. From a security perspective, it is very important not to provide information that gives up sensitive data. Paths to resources, databases, or other items that could be used by an attacker should not be disclosed. A common error is when the user enters incorrect credentials for access. If the user ID is correct but the password is wrong, confirming a password error tells a potential attacker that he got the user ID correct. The proper procedure is to tell the user that there is an authentication error, without identifying which field is wrong.

Privilege Escalation

Hacking a computer system is not a quick sit-at-the-keyboard-and-type-your-way-in Hollywood-style endeavor. There is a process for attacking a system, beginning with reconnaissance, moving to gain a foothold, and then escalating privilege to gain a level of control necessary to achieve an objective. All processes that run on a computer system do so under the label of a specific named account. Each account has a set level of privileges that it can use when accessing various resources. Typically end users have fairly limited privileges because they do not need to routinely perform many actions. Named accounts serve a variety of purposes, one of which is to regulate the level of control a user can have when interacting with a system. Shared resources, such as file systems, can have areas that are usable by different accounts, blocking other users from accessing these files.

Only one account has the ability to see all and do all in the system: the root or administrator account. A typical goal of many hackers is to achieve root or administrator status, because this allows them unfettered access to all system resources. As root they can start, stop, and change anything, including log files. Root accounts are typically protected with strong passwords, and access is logged and alerted to system operators. This makes direct logging into these accounts not a viable option.

Another way of gaining higher access is to exploit a vulnerability in an application that is running with elevated privileges. The exploit that allows arbitrary code to be run does so at the elevated privilege level of the application program, and does so under the application program’s legitimate credentials, thus reducing the alert footprint significantly. This is why vulnerabilities associated with privilege escalation are highly sought after by hackers.

Improper Storage of Sensitive Data

Applications frequently have data that could be considered sensitive, or of high value to an attacker. Passwords, encryption keys, paths, and other elements that the application needs to run correctly are common examples—but would cause harm if published. Maintaining these secrets is a key element of maintaining security associated with an application. There are many ways to store sensitive information, and like most things in life, the simple methods have drawbacks.

A simple encoding of a secret in strings inside the executable code has two distinct disadvantages. First, it makes strings difficult to change. The second and potentially more serious problem is that strings can be discovered via reverse engineering and code examination. This has led to the rule “no hard-coded passwords,” because numerous applications have fallen prey to this vulnerability. A hard-coded password is discoverable and, once known, is next to impossible to change without changing the code—and hence becomes a glaring vulnerability. This same issue applies to cryptographic keys because they, too, have been revealed in the same fashion.

Storing the data in a configuration file does not significantly improve the situation. Configuration files are frequently discovered, and if the secret is one that is common among installations, then simply obtaining a copy of the program in demo mode allows information as to how to obtain the secrets from a licensed version. Not only are configuration files sensitive, so are some forms of operational files. Printer files, whether a temporary file on a print server or a job file stored on a digital printer, can represent an opportunity for data leakage. Accessing a print queue, or set of temporary files, can result in data release.

Fuzzing/Fault Injection

Fuzzing is a software testing methodology used to detect input validation errors. This is a very powerful tool that is frequently automated to test a wide range of inputs against an interface. The basic concept is that one prepares a large set of input data to test a large range of potential input validation errors. The fuzzing framework then presents this to the application and monitors the system for exceptions. The code that results in exceptions is then examined for potential exploitability. A wide range of systems can be fuzzed—databases, shared memory, file systems—in essence anything with an input.

Fuzz testing has become a very powerful testing tool. Fuzzing is the mechanism that has found the majority of operating system bugs. The challenge for testers is how to build the dataset of inputs for testing. Originally the datasets were built randomly, but over time, the value of specific structures became apparent. Using a variable string length, followed by a payload, allows the tester to find exploitable buffer overflows. Specific sets of numbers can test for numerical overflows.

A related testing methodology is fault injection. Fault injection is the specific injection of faults into code, which can be done with inline code for testing, to verify correct handling of specific fault conditions. When inline code is used for testing, this code is removed before compiling for production, but this extra step is still an important and useful tool to verify correct handling of critical errors.

Secure Cookie Storage and Transmission

Cookies are an important part of web applications. Cookies provide client-managed storage in the form of text files that enable a web browser to locally store information from a web application. Cookies are often vulnerable with web browsers, and many methods of stealing cookies have been developed and exploited. It should be assumed that adversaries can get access to the cookies associated with an application. This places two burdens on application designers and developers. First, secrets stored in cookies must be encrypted. Simple encoding is not encrypting, so actual encryption methods should be used.

The second condition is that essential information should not be stored in the cookie, but rather on the application server itself. The cookie can store a pointer to the location on the server. By using the cookie to store a reference pointer (or session ID), the secrets associated with the cookie can be safely managed on the server side of the application. When e-commerce was first being developed, cookies were widely used to directly store the shopping cart contents for users. Web applications that stored the prices in this fashion found themselves vulnerable to having the prices changed on the client.

As with all things web related, transmission of data between client and server are often in clear text and subject to observation. To address this issue, all sensitive communications should be done over secure channels with SSL/TLS designed specifically for this functionality. Although sparsely used early in the Web, primarily for performance concerns, SSL has entered into mainstream usage today. In a modern IT enterprise, there is really no reason not to use SSL all the time, and there have been industry calls for SSL everywhere. This will place at least a reasonable level of complexity on an attacker going after application data transfers.

Buffer Overflow

A buffer overflow vulnerability is a result of poor coding practices on the part of the developer. It occurs when any program reads input into a buffer (an area of memory) and does not validate the input for correct length. The potential for a buffer overflow exists any time data is read into a memory location; if the size of the data being read is larger than the destination, then an overflow occurs, overwriting the memory buffer and potentially damaging other values or introducing executable code.

The exploit concept is simple: An attacker develops an executable program that performs some action on the target machine and appends this code to a legitimate response to a program on the target machine. When the target machine reads through the too-long response, a buffer-overflow condition can result in the original program’s failure. The extra data past the original buffer length can be malicious code that is now in the machine’s memory, awaiting execution. If the attacker executes it correctly, the program can skip into the attacker’s code, running it instead of crashing.

Buffer overflow mitigations come in several forms, including the following:

•   Bounds checking   The application checks an allocated block of memory to prevent inputted code from exceeding the allocated space.

•   Canary values   Like canaries that didn’t survive in a mine, a canary value is an added value that, if destroyed, symbolizes that the buffer preceding it in memory was overflowed.

•   Tagging   A method of tagging data types in memory. Tags serve as a nonexecutable barrier to prevent buffer overflows.

Memory Leaks

Computer programs use memory for a wide range of purposes, but one dynamic use is in the storage of objects, variables, and other resources. When an application has a need for more memory resources, it can request additional memory from the operating system. When the application is done with memory it has requested, how the memory is returned to the operating system is language dependent. Some programming languages (Java and C#, for instance) have automatic garbage collection capability that reclaims and returns memory when objects are no longer used. Other languages, such as C and C++, require the program itself to manage the allocation and deallocation of memory.

Failure to correctly manage memory can result in continued requests until the shared resource is exhausted. It may be in small steps, 1KB at a time, but in long-running programs even a small memory leak can have significant consequences. Better code review and development practices can help prevent memory leaks, in addition to the implementation of software patches.

Integer Overflows

Integer overflow errors occur when a number is too large to be stored in the variable. Also called arithmetic overflows, these errors can occur in many ways. The first is in the simple concept that a given number will require a specific size of register or variable to store the value. The second issue lies in how numbers are represented digitally. If the most significant bit of a number is used to represent the sign of a number, then adding two large positive numbers can cause this bit to flip, making the result negative. This overflow condition is not automatically trapped in all languages and can result in some spectacular errors.

The consequences of storage can be less than obvious as well. Consider an order entry system that has numeric values for unit price, quantity, and total price. It could be possible to roll over the total price and not the quantity, enabling an attacker to order a large quantity of an individual item and get it for a negative price (refund?). This type of error can be caught in several ways. First, all math should be checked prior to use. This will result in overflows being caught and then handled as exceptions.

A second check—and one that should be a routine check—is output validation. Whenever you have an output of a function, it is important to validate the output value as landing in an expected range. In the case of the order entry error previously described, a negative total price should trigger an exception. Combining a series of security checks is the time-honored principle of defense in depth.

Race Conditions

Race conditions are software flaws that arise from different threads or processes having a dependence on an object or resource that affects another thread or process. A classic race condition is when one thread depends on a value (A) from another function that is actively being changed by a separate process. The first process cannot complete its work until the second process changes the value of A. If the second function is waiting for the first function to finish, a lock is created by the two processes and their interdependence. These conditions can be difficult to predict and find.

Time of Check

When software is going to update or change some aspect of a resource, it is common to check the item before change. A common example is the checking to see if a file exists before creating the file. Based on the results of the check, a future action is performed. Should something change between the time of the check and the future use (that is, another process creates the file), an exception can occur at the future action.

Time of Use

Using a shared resource without locking the resource from other activity can create issues if multiple threads attempt simultaneous use that is precluded by the resource type. It is possible for multiple threads to read the same areas of a database, but updates, writes, and deletes are activities that cannot be shared across threads. Locking mechanisms are needed in these cases, yet performance may be an issue. Managing locking at an appropriate granular level is necessary to manage performance impacts from required time-of-use locks.

Resource Exhaustion

Resource exhaustion is a form of denial of service, where a required resource to perform some specific action is not available at the time of need. Shared resources are particularly vulnerable to this form of attack. A SYN flood attack is a resource-exhaustion attack. In a SYN flood, the multitude of SYN packets consume the system resources used to open connections. Many times, resource-exhaustion vulnerabilities stem from design issues, where protocols or architecture did not consider the handling of excessive demand and the resultant effects. This makes corrective action for these examples more difficult because the solution must be created out of band.

A common programming error involves nested loops that consistently use some form of resource without releasing previous use. Memory leaks are an example of this form of resource exhaustion. The end result of most resource-exhaustion attacks is a denial of service associated with the service being provided by the function under attack.

Geotagging

As detailed in Chapter 7, geotagging involves attaching geographical identification properties (location, coordinates, place names, and timestamps) to media such as photos, websites, videos, and so on. Certain applications like Foursquare are well known for their geotagging capabilities, particularly for publishing on social media platforms like Facebook. Some attackers on social media sites observe your geotagging data to determine your current whereabouts. It is recommended that unless absolutely necessary, geotagging should be disabled on smartphones and on social media websites.

Data Remnants

Confidential materials are often grouped together to simplify data retention, security, and destruction requirements. When the time comes, the organization will need to properly remove the data from its online and offline storage containers. Data, however, is not as simple to remove as just “deleting” it. It is often believed that deleting data means that all of the data just disappears. The data often remains where it is; what actually occurred was the “pointers” to the data were removed.

When pointers are removed during a file deletion, the file system now considers the still-occupied space as “unoccupied,” thus making it available for use. Any information that remains after file deletion or destruction techniques is known as a data remnant. As a benefit, data remnants provide businesses (and forensic investigators) with an opportunity to reconstruct lost data; yet it also provides attackers with the same opportunity.

To properly dispose of data to ensure little to no data remnants remain, consider the follow data-destruction techniques:

•   Overwriting   Involves the replacement of the 1’s and 0’s on the storage medium with a different pattern of 1’s and 0’s to render the original data unrecoverable. It is recommended that this process be repeated several times to ensure effectiveness. Physical destruction techniques are generally preferred.

•   Degaussing   Performed by sending a powerful magnetic force to the storage medium to destroy the information (and sometimes other physical components of the drive as well).

•   Encryption   Drive encryption, and the subsequent destruction of the decryption key, makes the information on the drive essentially unrecoverable. This is a cheap and fast alternative to other destructive techniques.

•   Physical destruction   Involves physically destroying the drive by shredding it, “burning” it with powerful chemicals, drilling holes in it, or incinerating it. This is the best technique, although typically the most expensive.

Use of Third-Party Libraries

Modern web applications are complex programs with many difficult challenges related to security. Ensuring technically challenging functionality such as authentication, authorization, and encryption can take a toll on designers, and these have been areas that are prime for errors. One method of reducing development time and improving code quality and security is through the use of vetted library functions for these complex areas. A long-standing policy shared among security professionals is, “Thou shall not roll your own crypto,” which is an homage to the difficulty in properly implementing cryptographic routines in a secure and correct fashion. Standard libraries with vetted calls to handle these complex functions exist and should be employed as part of a secure development process.

There are numerous vetted and secure libraries for use in applications, including the following:

•   Microsoft Web Protection Library (runtime protection from XSS and SQL injection)

•   OWASP Enterprise Security API input data validation and output encoding functions

•   OWASP AntiSamy

•   OWASP CSRFGuard

The use of tools such as these remove much of the tedium associated with secure coding and allow developers to focus on the actual application development as opposed to the secure implementation of functions.

Code Reuse

Code reuse involves the authorized use of someone else’s proven code, or knowledge about code, to improve your software development efforts. It can save time and resources as well as help create more usable, functional, and secure software overall. Oftentimes, the reusable code is stored within an organization for repurposing in the future; yet the reusable code is more likely to be sourced from third-party software development kits (SDKs) and software libraries.

Application Sandboxing

Application sandboxing is a mechanism to constrain an application into a confined area during execution. Limited access to the OS and persistent items, such as user files, permissions, and other resources, will limit the damage a malicious application can cause. The objective of the confinement can range from complete isolation to limited isolation, depending on the security needs. There are a variety of methods to implement sandboxing, from virtual machines (which sandbox a whole machine) to application-specific sandboxing (for example, JavaScript in a browser).

Although virtual machines are commonly used, recent advances in virtualization have introduced operating system virtualization—or containerization—into many operating systems, including Windows 10 and Windows Server 2016. Containers provide application isolation benefits without requiring nearly as many resources as virtual machines.

Secure Encrypted Enclaves

With malware increasing in complexity, operating systems (OSs) should operate under the assumption that they are already infected. An OS under the control of malware is a scary proposition for any system owner; therefore, a method is needed to ensure that malware-infected kernels cannot compromise the entire OS. This “safe” portion of the OS that is isolated from the malware is known as a secure encrypted enclave. These secure enclaves use a separate coprocessor from the system’s main processor to prevent the main processor from having direct access to information stored in the secure encrypted enclave. Such information may include encryption keys, biometric information, and so forth. This topic is discussed in more detail in Chapter 13.

Database Activity Monitors and Web Application Firewalls

Discussed in more detail in Chapter 5, database activity monitors (DAMs) independently monitor the transactions and other activity of database services. DAMs are important because databases contain some of the most important information in the organization; therefore, many attacks concentrate on databases. Common uses of DAMs include monitoring applications and users for unauthorized or fraudulent activity, such as SQL injection attacks. Accountability and compliance auditing can also be aided by DAMs.

Also discussed in more detail in Chapter 5 is the usage of web application firewalls (WAFs). WAFs are firewalls created for web applications to impart HTTP-specific rules to guard against a variety of attack vectors, including everything from cross-site scripting and session hijacking to SQL injection and file injection attacks. Web applications are both easily accessible and stacked with valuable data; therefore, they routinely endure more attack vectors than most targets.

Client-Side Processing vs. Server-Side Processing

Client-side processing versus server-side processing is a classic case of input validation. Although client-side processing has many advantages, it is not appropriate as a standalone security solution. Client-side processing can be circumvented by a proxy between the client and the server, and values can be changed. This does not mean client-side processing is without value. Client-side processing is very useful when it comes to user experience, because it is faster than a round trip to the server. The best practice is a form of client-side processing to validate and correct inputs on the client machine, thus affording the user the best user experience.

The material is then rechecked for appropriate input on the server before processing. This server-side check acts as the real input validation, preventing any input overflow or canonicalization errors. The key element behind input validation is that one cannot trust the client for proper input, so one cannot trust the client for validation either. The true culprit is not just the client, but also any machines that may be between the client and the server, including proxies. Any processing before the server can be changed during transmission, so the only secure way to verify input validation is on the server side of the conversation.

JSON/REST

JavaScript Object Notation (JSON) is a language-independent data format derived from JavaScript. It utilizes a simple text format for the storage and exchange of data between a browser and web applications. JSON is similar to Extensible Markup Language (XML), yet JSON’s lack of verbosity makes it a popular alternative to XML.

Representational State Transfer (REST) is a framework that relies on various web protocols to define how clients and servers can exchange web resources with a high degree of interoperability. REST is often preferred over SOAP since it is lighter weight, consumes less bandwidth, works with more tools, and has better scalability. Any web services that use REST are referred to as “RESTful APIs.” The following security techniques should be considered for JSON/REST web services communications:

•   Use API keys to prevent service hijacking, which can lead to DoS conditions.

•   Implement access control at API endpoints.

•   Implement audit logs.

•   Employ input validation.

•   Restrict HTTP methods to only allow GET, POST, and PUT.

•   Use HTTPS to secure the communication’s channel.

•   Use nonverbose error messages.

•   Utilize JSON web tokens for the security token, which can then be digitally signed for integrity.

Browser Extensions

Browser extensions, also known as add-ons or plug-ins, are tiny programs connected to a web browser to provide extra functionality. Browser extensions can run the gamut, from providing translation services to blocking web ads. Although extensions typically don’t modify the interface, some extensions include toolbars, which are typically visible on the top portion of the web browser. Most browser extensions are made available through app stores, such as with Chrome’s Web Store. In this section, we cover a few technologies that provide functionality to browser extensions.

ActiveX

Released in 1996, ActiveX is a Microsoft software framework designed for Internet Explorer, built on object-oriented programming technologies, for the purpose of running dynamic media content. ActiveX repurposed its Component Object Model (COM) and Object Linking and Embedding (OLE) technologies to facilitate the running of programs, or ActiveX controls, inside the browser itself. Such controls permitted the browser to display videos, animations, and documents directly from the browser without requiring separate software.

Controversial from the start, ActiveX controls run on the local computer with the same security privileges as the currently logged-on user, thus providing potential loopholes into your system for attackers. Although ActiveX is still supported by Internet Explorer 11, its days are numbered. The Microsoft store no longer supports ActiveX, and Microsoft’s newest Edge browser does not support ActiveX. For security purposes, you may want to make sure that ActiveX support is disabled on your browser.

Java Applets

Developed by Sun Microsystems in 1995, Java applets are small platform-independent and Internet-based programs accessible within a web browser. More accurately, the Java program, or “bytecode,” would execute within a Java virtual machine (JVM), which was a separate process from the web browser. Such isolation helped provide a baseline of security between the web browser and the operating system.

Although Java applets are in the process of being deprecated in favor of JavaScript, they are a relic of an earlier time when web pages were static and didn’t do much of anything. Java applets helped usher in the current generation of dynamic website applications that are chockfull of rich multimedia content. It’s important to keep in mind that, like ActiveX controls, Java applets may be hostile in nature and can cause damage to a machine if downloaded, so care must be taken in their usage. Options exist within web browsers to disable Java applets to improve host security.

HTML5

Created in 2008, HTML5 is the fifth generation of the HTML markup language, which is used for describing the contents and appearance of web pages. HTML5 has been enhanced to support more multimedia capabilities, added mobile device support, plus many other features. Although HTML5 is comparable to Adobe Flash in certain ways, and is, essentially, the de facto replacement to Flash, HTML5 cannot do everything that Flash does—hence the need for supplementing HTML5 with JavaScript or Cascading Style Sheet (CSS) content.

With HTML5’s new features also come new security risks—one of which is called cross-domain trusts. This feature permits websites from different DNS domains to communicate between iframes in your web browser. Such integration across websites will embolden malware writers to exploit cross-domain trust vulnerabilities. Plus, with HTML5’s increased reliance on client-side input validation, servers might fall prey to an increase in client-side attacks. Servers and web browsers will need to be programmed and configured to ensure input validation is also performed on the server.

AJAX

AJAX is an acronym for Asynchronous JavaScript and XML and is a common programming methodology used to improve the end-user experience in web applications. AJAX is an intricate combination of technologies that can add complexity in an application. It can also increase the workload on the client machine. AJAX is a combination of the following technologies, and security issues associated with any of these can manifest themselves in an AJAX environment:

•   HTML or XHTML with CSS for presentation

•   DOM for dynamic presentation and interaction with data

•   JSON or XML for data exchange

•   XSLT for data manipulation

•   XMLHttp Request object for asynchronous communication

•   JavaScript to unite technologies together

AJAX techniques can run into issues crossing domains because of the same origin policy, which is a security concept designed to prevent scripts from operating across different domains; scripts that attempt to access methods and properties are limited to staying within the script’s origin domain.

SOAP

Developed by Microsoft while relying on XML, SOAP is a specification for exchanging information associated with web services. Using a combination of protocols (including XML, HTTP, and SMTP), SOAP can transmit messages across the Web. SOAP acts as a specifically designed messaging framework between applications. SOAP creates a web services application stack that defines what is in a message, how to process the message, application-defined data types, and a convention to describe procedure calls and responses. This information is then used to define communications between applications.

SOAP was created as an object access protocol with three major characteristics: extensibility, neutrality, and independence. SOAP can be extended with security and WS-Routing protocols. SOAP can be used across a wide range of transport protocols, including TCP, HTTP, and SMTP. The independent nature of SOAP, and its basis in XML, allows it to be used with virtually any programming language or model.

A SOAP message has two major components: the envelope and the body. The envelope defines the elements of the body so that a web service understands how to interpret a message. The body element contains call-and-response information as well as a fault element containing error information. The typical SOAP exchange involves a request message and a reply message. The Web Service Definition Language (WSDL) describes a web service and the format of requests processed using SOAP.

For example, you log into your organization’s online learning management system (LMS) portal in order to click a link that launches a virtual classroom session hosted by Adobe Connect. Upon you clicking the link, the LMS then packages both the link request and your authentication data into a Security Assertion Markup Language (SAML) format, which then gets encapsulated into a SOAP message for transmission to the Adobe Connect server over an HTTP connection. As you can see, SOAP provides a means of exchanging structured information.

A SOAP message is a basic XML document made up of the following components:

•   Envelope   Categorizes the XML document as a SOAP message

•   Header   Stores header information

•   Body   Contains call-and-response data

•   Fault   Provides error information during message processing

From a security perspective, SOAP will benefit from web services security (WS-Security), which is a security extension for SOAP messages. WS-Security can specify signing SOAP messages for integrity, encrypt messages for confidentiality, and attach security tokens to identify the sender.

State Management

Web applications commonly rely on an external form of state management. This is because, by design, the Web itself is stateless, not knowing the previous page or data. State can be managed in a variety of manners, but the two primary means are both via cookies—with the state being maintained either in the cookie itself or on the server via a lookup process. For some applications, keeping the actual state in the cookie can make sense, because if the manipulation of the state via the cookie does not cause harm, this can lessen the burden on the server itself. But as many an e-commerce vendor has learned, keeping a shopping cart in a cookie and relying on the prices in the cookie are two different things. Keeping the items in a shopping cart in a cookie can enable a better web experience. But when it comes time to check out, it is imperative that the server validate the critical input before use. In the case of the shopping cart, this would mean not relying on the client for pricing, but rather on the secure price stored in the server. Keeping prices in a cookie and relying on them can result in a disaster when the prices are altered to a penny or a negative number, thus creating a refund condition.

JavaScript

JavaScript is a scripting language developed by Netscape and designed to be operated within a browser instance. The primary purpose of JavaScript is to enable features such as validation of forms before they are submitted to the server. Enterprising programmers have found many other uses for JavaScript, such as manipulating the browser history files (now prohibited by design). JavaScript actually runs within the browser, and the code is executed by the browser itself. This has led to compatibility problems, and not just between vendors, such as Microsoft and Mozilla, but between browser versions. Security settings in Internet Explorer are created by a series of zones, allowing differing levels of control over .NET functionality, ActiveX functionality, and Java functionality. Unfortunately, these settings can be changed by a Trojan program, altering the browser (without alerting the user) and lowering the security settings. In Firefox, using the NoScript plug-in is a solution to this, but the reduced functionality leads to other issues—it can break many applications and requires more diligent user intervention.

Although JavaScript was designed not to be able to access files or network resources directly, except through the browser functions, it has not proven to be as secure as desired. This fault traces back to a similar fault in the Java language, where security was added on without the benefit of a comprehensive security model. Therefore, although designers put thought and common sense into the design of JavaScript, the lack of a comprehensive security model left some security holes. For instance, a form could submit itself via e-mail to an undisclosed recipient, for either eavesdropping, spamming, or causing other problems—imagine your machine sending death threat e-mails to high-level government officials from a rogue JavaScript implementation. Further, most browsers do not have a mechanism to halt a running script, short of aborting the browser instance, and even this may not be possible if the browser has stopped responding to commands.

Malicious Java scripts can do many things, including opening two new windows every time you close one, each with the code to open two more. There is no way out of this, short of killing the browser process from the operating system. Java scripts can also trick users into thinking they are communicating with one entity when in fact they are communicating with another. For example, a window may open asking whether you want to download and execute the new update from http://www.microsoft.com…./update.exe, but what is covered by the ellipsis (…) is actually “www.microsoft.com.attacker.org/”. The hope is that you’ll assume this is a Microsoft address that is cut short due to space restrictions on the display.

Operating System Vulnerabilities

Regardless of the OS you’re using, it will have vulnerabilities—and a lot of them. Don’t believe any vendor hype that suggests otherwise. Although operating system vulnerabilities is a large topic in itself, we broke it down nice and easy for you:

•   Unnecessary services   When in doubt, leave it out. If you’re running a Windows IIS web server, you can probably disable NetBIOS and SMB services. Unnecessary services lead to open ports, which lead to malicious vulnerability research and exploitation. Disable any services that are not required.

•   Encryption   One of the golden rules of cryptography is that you do not make your own cryptographic algorithms. The odds are miniscule that you’ll invent something better. Not only should you use other cryptographic algorithms, but its important to use the right ones. For symmetric encryption, AES is always a great choice. Same with RSA, ECC, or a variation of the two for asymmetric encryption. SHA-256 or better is a safe bet with hashing. IPSec is a strong choice for VPN. TLS 1.2 or 1.3 should be used for secure web communications, and at least WPA/2 personal or enterprise should be used for wireless communications.

•   Hardening   Hardening is about changing default settings. Although this is by no means an exhaustive list, Windows hardening may involve modifying registry settings, group policies such as password policies, account lockout policies, auditing, user rights assignment, and AppLocker settings. Also, don’t forget to enable BitLocker drive encryption and Encrypting File System (EFS). In Linux, consider locking the boot directory, disabling USB support, removing unnecessary software packages, hardening the SSH service, enabling SELinux for kernel protection, and modifying default permissions.

•   Open ports   Although some open ports are necessary, such as ports 80/443 for web servers, ports 25/110/143 for e-mail servers, and so on, make sure no stragglers are open. Such ports could be a sign of backdoor Trojan horses, or unnecessary services still enabled.

•   Patch   Patch management is a bit of a double-edge sword. If you install patches immediately after release, you risk system reliability issues due to lack of quality assurance patch testing. If you perform lengthy quality assurance testing, you risk leaving your systems open for exploitation. The trick is to balance the need for thorough quality assurance testing with the need for expedient patch management. Most patches target vulnerabilities; therefore, it is imperative that they are deployed into the production environment as soon as possible.

Firmware Vulnerabilities

Often tossed aside in favor of mitigating operating system vulnerabilities, outdated firmware can produce serious vulnerabilities. It is alarming how infrequently technicians update system firmware. There are three misguided beliefs driving this administrative pattern:

•   Firmware updates don’t provide any noticeable benefits.

•   The risk of bricking the firmware entirely outweighs the benefits.

•   The current firmware works just fine, so “if it ain’t broke, don’t fix it.”

Although it’s true that firmware updates generally don’t add new functionality or features, they often mitigate security issues. That, in itself, is worth the update every time. Many bulletins out there describe hackers exploiting network appliances with older firmware. Not only should we update the firmware, but we need to account for just how many devices have firmware. These devices include the following:

•   Workstations/servers

•   Routers/switches/firewalls

•   NAS systems

•   Mobile devices

•   Smart TVs

•   Hard drives

•   Optical drives

•   Expansion cards/peripherals

•   Cameras

•   Scanners

•   Gaming consoles

Chapter Review

In this chapter, we covered the selection of appropriate security controls given software vulnerability scenarios. The first section began with a discussion on application security design considerations such as applications and solutions being secure by design, secure by default, and secure by deployment.

The next section went into numerous application issues, beginning with insecure direct object references, which can be addressed by the application developer. Then we talked about common web application vulnerabilities for cross-site scripting and cross-site request forgery, which are heavily reliant on input validation countermeasures. Next, we talked about clickjacking, which tricks users into clicking on malicious web content. We then went into session management concepts like the usage of HTTP, session IDs, and how session hijacking works. We talked about input validation and how it can prevent many of the common web application attack vectors. SQL injection was discussed and how it exploits input validation weaknesses in web applications, leading to database breaches. Next was improper error and exception handling and how verbose error messages provide too much information for attackers to take advantage of. We discussed privilege escalation and how it allows attackers to increase their permissions/rights to have more powerful access on systems. We talked about improper storage of sensitive data regarding lack of encryption or password protection of sensitive content. Next was fuzzing/fault injections, which provide a way of testing a system with junk commands to see how it responds. We talked about secure cookie storage and transmission to ensure proper construction and transmission of cookies, in addition to encrypted channels with HTTPS. We talked about the ageless buffer overflow attacks and how they can be used in a DoS attack against an application or allow attackers to take control of the application. Memory leaks are bad because they can deprive a system of memory resources. Integer overflows are caused by calculations too complex for processing, which can lead to system or application crashes. We discussed race conditions, which involve out-of-order issues with the processing of software instructions. The next topic was resource exhaustion and how systems can crash if deprived of their primary resources. We discussed geotagging and the privacy issues it creates. Data remnants are leftover pieces of data after deletion operations have completed. We discussed the use of third-party libraries to augment our software development processes, as well as code reuse to provide increased efficiency and consistency of coding.

The next section went into application sandboxing and its various incarnations, including the usage of virtual machines or containers for isolation purposes. Sandboxing can be done on-premises or in the cloud.

Another section went into secure encrypted enclaves, describing the isolation of a portion of the OS should the kernel become compromised. This is achieved through the use of a separate processor assigned to the isolated portion of the OS.

The next section tackled database activity monitors (DAMs), which are vital for monitoring database activity, including queries and responses, while also checking for SQL injection commands.

We then had a section on web application firewalls (WAFs) and the specific role they play in guarding our valuable but vulnerable web applications. Web applications are targeted so often that they require their own defense-in-depth strategy, which includes the use of web application firewalls.

The next topic covered client-side processing versus server-side processing of web content. Client-side processing provides better performance and functionality for the users, whereas server-side processing improves security. We also went into various web services methods like JSON/REST, HTML5, AJAX, JavaScript, and SOAP. We talked about browser extensions, including the soon-to-be deprecated ActiveX controls and Java applets. We also talked about state management of web sessions.

We ended the chapter on operating system vulnerabilities, including the need for hardening, disabling unnecessary services and ports, enabling encryption, and improving patch management. We also touched on firmware vulnerabilities and the need to update firmware to improve security.

Quick Tips

The following tips should serve as a brief review of the topics covered in more detail throughout the chapter.

Application Security Design Considerations

•   Secure by design means that an application has considered the threat environment it will be operating within and that it appropriately uses available technology to achieve security.

•   Secure by default refers to the principle that when an application is deployed in a default configuration, security is maintained.

•   Secure by deployment means that an application is deployed into an environment that will support the security goals of the application.

Specific Application Issues

•   A direct object reference occurs when an application request refers to the actual name of objects, such as files, folders, database, or storage elements.

•   Cross-site scripting involves attackers discovering and exploiting vulnerabilities on websites in order to inject malicious code—typically JavaScript.

•   CSRF attacks are the result of malicious code found in e-mails, websites, or instant messages and cause a user’s web browser to execute undesired actions on a site to which the user is already authenticated.

•   Clickjacking is an attack where a user is tricked into clicking something on a web page, causing a different operation than the one expected to be performed.

•   State management is generally performed through the use of cookies and session IDs.

•   Input validation involves screening all input to ensure it is in proper form and length before processing.

•   SQL injection is designed to attack the database associated with a web application.

•   Improper error and exception handling occurs when an error message provides too much information to the attacker, thus revealing vulnerabilities.

•   Privilege escalation seeks to elevate the privileges of the currently logged-on user to a higher level to increase control over the compromised system.

•   Improper storage of sensitive data occurs when data is not encrypted or password-protected in storage.

•   Fuzzing is a software testing methodology used to detect input validation errors.

•   Cookies provide client-managed storage in the form of text files that enable a web browser to locally store information from a web application.

•   Buffer overflows occur when the size of the data being read is larger than the destination buffer, which causes an overflow condition resulting in application failure.

•   Memory leaks result in the failure of an application to correctly manage memory, which can lead to a memory shortage.

•   Integer overflow errors occur when a number is too large to be stored in the variable.

•   Race conditions are software flaws that arise from different threads or processes having a dependence on an object or resource that affects another thread or process.

•   Resource exhaustion is a form of denial of service, where a required resource to perform some specific action is not available at the time of need.

•   Geotagging involves attaching geographical identification properties (location, coordinates, place names, and timestamps) to media such as photos, websites, videos, and so on.

•   Data remnants are any unwanted pieces of information that remain after a deletion operation.

•   Use of third-party libraries helps reduce development time and improves code quality and security.

•   Code reuse involves the authorized use of someone else’s proven code, or knowledge about code, to improve your software development efforts.

Application Sandboxing

•   Application sandboxing is a mechanism to constrain an application into a confined area during execution.

•   Limited access to the OS and persistent items, such as user files, permissions, and other resources, will limit the damage a malicious application can cause.

•   Although virtual machines are commonly used, recent advances in virtualization have introduced operating system virtualization—or containerization—into many OSs, including Windows 10 and Windows Server 2016.

Secure Encrypted Enclaves

•   With malware increasing in complexity, operating systems should operate under the assumption that they are already infected.

•   Secure enclaves use a separate coprocessor from the system’s main processor to prevent the main processor from having direct access to information stored in the secure encrypted enclave.

Database Activity Monitors

•   Database activity monitors independently monitor the transactions and other activity of database services.

•   Common uses of DAMs include monitoring applications and users for unauthorized or fraudulent activity such as SQL injection attacks.

Web Application Firewalls

•   WAFs are firewalls created for web applications to impart HTTP-specific rules to guard against a variety of attack vectors, including everything from cross-site scripting and session hijacking to SQL injection and file injection attacks.

•   Web applications are both easily accessible and stacked with valuable data; therefore, they routinely endure more attack vectors than most targets.

Client-Side Processing vs. Server-Side Processing

•   Client-side processing is very useful when it comes to user experience, because it is faster than a round trip to the server.

•   Server-side processing acts as the real input validation, preventing any input overflow or canonicalization errors.

•   JavaScript Object Notation (JSON) is a language-independent data format derived from JavaScript. It utilizes a simple text format for the storage and exchange of data between a browser and web applications.

•   Representational State Transfer (REST) is a framework that relies on various web protocols to define how clients and servers can exchange web resources with a high degree of interoperability.

•   Browser extensions, also known as add-ons or plug-ins, are tiny programs connected to a web browser to provide extra functionality.

•   ActiveX is a Microsoft software framework designed for Internet Explorer, built on object-oriented programming technologies, for the purpose of running dynamic media content.

•   Java applets are small platform-independent and Internet-based programs accessible within a web browser.

•   HTML5 is the fifth generation of the HTML markup language, which is used for describing the contents and appearance of web pages. HTML5 has been enhanced to support more multimedia capabilities, added mobile device support, plus many other features.

•   AJAX is an acronym for Asynchronous JavaScript and XML and is a common programming methodology used to improve the end-user experience in web applications.

•   SOAP is a specification for exchanging information associated with web services.

•   State can be managed in a variety of manners, but the two primary means are both via cookies, with the state being maintained either in the cookie or on the server via a lookup process.

•   JavaScript is a scripting language developed by Netscape and designed to be operated within a browser instance.

Operating System Vulnerabilities

•   Operating system vulnerabilities can include unnecessary services, lack of encryption, lack of hardening, open ports, and missing patches.

Firmware Vulnerabilities

•   Firmware vulnerabilities generally result in serious security issues.

•   Firmware updates generally don’t add new functionality or features; they often mitigate security issues.

Questions

The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully because there might be more than one correct answer. Choose all correct answers for each question.

1.   Which of the following is not a web application security design consideration?

A.   Secure by design

B.   Secure by test

C.   Secure by deployment

D.   Secure by default

2.   Input validation can be employed to guard against all of the following errors except which ones? (Check all that apply.)

A.   Buffer overflow

B.   TOCTOU race conditions

C.   Privilege escalation

D.   SQL injections

3.   You are concerned about users of your web application being subjected to a clickjacking-type attack. What is the best defense you can offer?

A.   Use the SECURITY=RESTRICTED header.

B.   Use a cookie with an encrypted session ID.

C.   Use a JavaScript frame-busting script to prevent iframe incorporation.

D.   Use the X-FRAME-OPTIONS header.

4.   Using hex encoding of Unicode input is associated with which of the following?

A.   SQL injection

B.   Directory traversal attack

C.   Cross-site scripting

D.   Canonicalization error

5.   A cross-site scripting attack is characterized by which of the following?

A.   Application code that returns user input in HTML without validation checking

B.   A hidden layer to trick a user into clicking an undesired option

C.   The alteration of code used against a database

D.   Cookie stealing

6.   To constrain an application to a confined area during execution is a reference to:

A.   Application quarantining

B.   Tests to detect memory leaks

C.   Input validation

D.   Sandboxing

7.   You are the application designer for a new web application at work. Where is the preferred location to store the key used for encrypting data in the application?

A.   Store it in a config file, so it can be changed if needed.

B.   Put it in a database during the install and allow only the application to have read access.

C.   Store it on the server, but force a new, fresh random key with each install for uniqueness.

D.   Store it on the server, protected from all but the application by ACL.

8.   During application testing, fault injection can be used to search for which of the following?

A.   Off-by-one errors in loops

B.   Correct handling of specific errors

C.   Buffer-overflow errors

D.   Arithmetic errors

9.   To ensure a fast and seamless user experience, AJAX is being used on the client side. With this configuration, where is the best location for input validation and why?

A.   On the server, because AJAX takes extra bandwidth for checks

B.   On the client, because AJAX can speed up the work, thus improving the customer experience

C.   On the server, because this prevents post-browser attack

D.   On the client, because AJAX blocks post-browser attacks

10.   There has been a lot of talk recently concerning buffer overflows at your firm. Management has decreed zero tolerance for buffer overflows in all future code. Is this possible, and why or why not?

A.   Yes, it has been done; it just requires careful examination of all buffer inputs.

B.   Yes, there is a library call to fix it.

C.   No, this is one of the errors that is almost impossible to completely remove.

D.   No, legacy code makes this impossible.

11.   You are testing an application for arithmetic errors. What is your best tool?

A.   Fault injection

B.   A fuzzing framework

C.   Code walkthroughs

D.   Use of specific library calls for math functions

12.   You are receiving reports of a random locking up of your application that you cannot replicate. What is the most likely cause?

A.   Injection flaw

B.   Memory leak

C.   Buffer overflow

D.   Race condition

13.   You have a corporate standard requirement that all in-house software must have a standard auto-update module that checks for and applies code updates automatically. This is an example of what?

A.   An application security framework

B.   Secure by deployment

C.   Secure by default

D.   Coding standards

14.   Your application is going to e-mail results to other users based on program logic. To perform this function, you incorporate a set of library calls to an e-mail program requiring administrative access permissions to perform the task. What type of attack should you be concerned with in employing this methodology?

A.   Impersonation attack

B.   Improper storage of sensitive data attack

C.   Fuzzing attack

D.   Privilege-escalation attack

15.   Your newest application has been having a variety of issues with conflicts and bugs. Management has decided to sandbox the application. What are the important details that need to be known to correctly sandbox the application?

A.   Exact enumeration and details of system resources needed by the application

B.   The language the application is written in

C.   The default storage location of the executables and config data

D.   How big the memory footprint is

Answers

1.   B. Testing cannot add security to an application; it can only catch where holes are. It is possible to miss holes with incomplete testing; hence, you can’t test security into software.

2.   B, C. Input validation is of no use in detecting time-of-check/time-of-use race conditions, nor will it help detect cases of privilege escalation.

3.   D. The X-FRAME-OPTIONS header with the DENY or SAMEORIGIN option is the best server-side defense against clickjacking-type attacks.

4.   D. Canonicalization errors are those that exploit the process by which application programs manipulate strings to a base form, creating a foundational representation of the input, to avoid input validation detection of invalid input.

5.   A. Cross-site scripting involves inserting scripts into user inputs to get them to run on a server to return altered HTML pages.

6.   D. Application sandboxing is a mechanism to constrain an application into a confined area during execution.

7.   C. All secrets need to be stored in a protected form on a server, away from unauthorized access. The addition of the random changing element prevents someone from learning the secret from another installation (such as a demo install) and using this knowledge to break a production installation.

8.   B. Fault injection is used to test the correct handling of exceptions.

9.   C. The only place input validation for security reasons can be properly done is on the server because the responses are editable via proxy machines between the client and the server.

10.   A. Buffer overflows are completely preventable, and numerous software projects have shown this. The key is in using multiple methodologies to defend against this type of coding error, including walkthroughs, library call utilization, and fuzzing.

11.   B. A fuzzing framework is the best tool for input validation errors, of which arithmetic errors are one example.

12.   D. Race conditions are the types of errors hardest to replicate, and they leave no obvious signs, such as increased memory use.

13.   B. Having auto-update capability improves the security of the application because it is deployed in an enterprise; hence, secure by deployment is the best answer.

14.   D. A failure that occurs during the escalated privilege function of the e-mail library could result in an exploitable privilege escalation against the application.

15.   A. To properly sandbox the application, one needs to know what interactions it must have with outside resources to function as built. These elements can then be used to determine safe access.