Case Study 2

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Web Applications: Architectures & Security

Introduction to Web Applications

An application is software that operates on a physical computing device such as a desktop computer, laptop, or server. Examples of applications that reside on a computer are Microsoft Internet Explorer (IE), Apple QuickTime, and Adobe Acrobat Reader. Computer applications are configured to work on a user's system, but are usually not easily shared across multiple networks, let alone the Internet.

Web applications are designed to address this challenge. A Web application is an application that can be made accessible over the Internet or an intranet (depending on the organization's preference). An organization using an application to sell products would want its application to be Internet-accessible (enabling customers to access it). However, an organization would want its human resources Web application to be accessible via intranet only because only employees would need to access it, and it could contain sensitive data.

Users access Web applications by directing their Web browser (Microsoft IE or Mozilla Firefox, for example) to the Uniform Resource Locator (URL) for a Web server. This server provides the user with access to the Web application and any databases which the application needs to support its functions. Any Web site that allows users to interact with the site in a dynamic way–that is, that allows users to determine the type of content provided to them–is a Web application. Organizations that use Web applications include the following:

• Banks – Banks that have Web sites, such as Bank of America, allow users to check their account balances, transfer funds, pay bills, select investment products, and so on;

• Federal agencies – Federal agencies use Web sites to deliver information and services to citizens, employees, businesses, and others;

• Online retailers – Online retailers such as Amazon allow users to browse items for purchase, select items, add items to a virtual shopping cart, and provide a method of payment;

• Travel reservation Web sites – Travel Web sites allow users to select flight, hotel, and rental car availability according to the individual’s preferences.

Web Architectures

A basic architecture for a Web application includes a Web server and the programs or scripts which provide interactivity. Database servers are frequently added to the Web architecture to provide additional functionality and access to information that is not part of the Web site itself.

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Web Servers

Web servers are typically hosted in a cloud computing environment using virtual machines rather than on a single physical machine (in times past, Web servers were dedicated machines with their own network connections and storage devices). The purpose of the Web server is to provide a mechanism for granting users access to a Web application. A Web server can be exposed to the Internet, which makes it accessible to everyone with an Internet connection, or, if it only needs to be used by a single organization, it can be configured to be available only to the organization's intranet. On the upper end of the spectrum, Facebook requires over 60,000 Web servers to sustain the 400 million active users connecting to its Web site (Miller, 2010). On the lower end of the spectrum, a single Web server may host only dozens of Web sites.

Web Applications

Web Applications, in the form of Applets and scripts, reside on the Web server and are the actual interface through which users perform various activities on the system. In the case of an online retailer, the Web application provides the interactive functions of the Web site that allow customers to browse products for purchase, to place their orders, to check their order status, and so on. Applets and scripts may be written in one or more programming (code) or scripting (script) languages which provide instructions to the computer.

Figure 4.1. Web Server, Web Application, and Script

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Databases and Database Servers

The database is the repository (storage files) for data that the Web application uses respond to queries and populate interactive Web pages. The data can be credit card information, medical information, usernames and passwords, and/or any other type of information that the organization collects. For example, when a user logs in to a Web application, the user's username and password information compared against the user authorization record stored in the database.

The database server is a sophisticated software application which manages the contents of the database files and provides other functions (including access control, queries / searches, and report generation). For security reasons, most Web application architectures require a database server which is separate from the Web server. While it is possible to host the Web server and the Database Server software on the same physical or virtual machine, this is a poor security practice since a successful attack against the Web server could compromise the database server and vice versa.

The recommended architecture for a database server is to host the software and database files on their own physical or virtual machine. This allows the system administrator to tune the system parameters for optimum performance. Separating the database server and files from other types of servers also allows the administrator to implement security controls which are specific to the functions required of the database server.

Database administrators (those responsible for the database server) manage data and database operations using structured query language (SQL). SQL allows a database administrator to give instructions to the database and to perform operations on the data itself. Instructions may be to look up records, to delete records, to add records, to modify records, to back up tables of data, and so on.

Figure 4.2 The Relationship between the Database Server, Data, and SQL Instructions

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Now that we have an appreciation for the fundamental components of Web applications, we will examine the relationship these components have to each other. The figure below shows a user accessing a Web application; in this case, Alice is accessing her bank information through her bank's Web site.

Figure 4.3 User Accessing a Web Application

Threats to Application Security

It is important to note that there are a few core concepts of Web application security that help the Web application to protect the data the application uses for operation:

• The Web application serves as an intermediary between the user and the database server. In the example above, it would compromise security to allow Alice to access the database directly because she would then have access to other users' data. The Web application is responsible for deciding what data is provided to Alice and from Alice.

• The Web application should only allow certain types of input to be processed from users. The Web application should not accept unauthorized instructions.

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

• The database server should only allow certain types of input to be processed from the Web application. The database server should not automatically assume that any instruction from the Web application is safe.

There are three types of threats to application security:

1. cross-site scripting 2. SQL injection 3. business logic vulnerabilities

Cross-Site Scripting

Cross-site scripting (frequently abbreviated to XSS) is an attack on the privacy of users of a Web site, which can lead to a total breach of the security of sensitive information (such as credit card numbers, passwords, and medical information). In cross-site scripting, malicious users put script into Web pages that lets them gain access to sensitive information stored on the Web site.

As listed above, one of the core security concepts of Web applications is "The Web application should only allow certain types of input to be processed from users." In the case of cross-site scripting attacks, the Web application is not properly validating input received by the user. Input validation refers to the methods the Web application employs to verify that input is not malicious, inaccurate, or otherwise inappropriate.

Consider the following example: An online retailer allows customers to place and pay for orders. Two key pieces of data in these interactions are order quantity and customer address.

• order quantity–The application asks for order quantity. The application should ensure that these rules are followed:

o Only numbers that are three digits or fewer should be used (users should not be permitted to submit an order for 1,000 units if only 900 units are available).

o Only numbers should be allowed (letters and special characters should not be permitted).

o Only positive numbers should be permitted (customers should not be permitted to submit negative orders).

• customer address–The application asks for the customer's address. The application should ensure that these rules are followed:

o Only numbers and letters should be allowed (special characters [&%$*($] should not be permitted in the address field).

o For the zip code, only numbers should be permitted (letters and special characters should not be allowed).

o The city and state should be places that exist (customers should not be permitted to submit orders to locations not on the Web application's city/state/country list).

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Attackers take advantage of a lack of input validation to submit malicious scripting information so that instead of displaying an order checkout summary to a customer, the Web application may be configured to run a series of instructions against the customer's machine. For example, instead of populating a username field with a legitimate username, an attacker may use the field to submit malicious script that will attempt to steal sensitive information from a user.

The username field shown in figure 4.4 is not properly validating the input of the user. It is allowing special characters (<>";/=), it is allowing more characters than it should, and it is allowing characters specifically identified as script that will enable malicious instructions to be run on the Web application.

Figure 4.4 Cross-Site Scripting Attack

According to WhiteHat Security, an organization that provides application security scanning services, cross-site scripting vulnerabilities are the most common application-level vulnerabilities present in Web applications (Grossman, 2010). Cross-site scripting attacks are designed to steal cookies, which are then used to assume the identity of the compromised user for the purposes of information or identity theft.

Figures 4.5 – 4.10 illustrate the steps taken in a cross-site scripting attack:

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Figure 4.5 Anatomy of a Cross-Site Scripting Attack

Figure 4.6 Phase 1 of the Cross-Site Scripting Attack

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Figure 4.7 Phase 2 of the Cross-Site Scripting Attack

Figure 4.8 Phase 3 of the Cross-Site Scripting Attack

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Figure 4.9 Phase 4 of the Cross-Site Scripting Attack

Figure 4.10 Final Phase of the Cross-site Scripting Attack

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

For a cross-site scripting attack to succeed, the attacker needs a victim to click on a malicious link. The attacker can get a victim to do this through the following:

• e-mail –The attacker can send an e-mail containing a link to the malicious Web site, or the e-mail can contain portions of the compromised Web site itself. Because the link will take the user to the actual legitimate Web site's Web server, many recipients will not suspect an attack.

• Browsing –The attacker can simply upload malicious script to the target Web site and wait for unsuspecting victims to visit the location of the script.

SQL Injection

An SQL injection is an attack that involves the introduction of unsolicited SQL statements into a Web application.

As we stated previously, one of the core security concepts associated with Web applications is "The database server should only allow certain types of input to be processed from the Web application." As with cross-site scripting attacks, SQL injection vulnerabilities are present as a result of input not being validated properly. For SQL injection vulnerabilities, however, it is the database that is not adequately validating input received from the Web application rather than the Web browser not validating input. In the SQL injection case, the database is allowing an improper construction of SQL instructions (also referred to as SQL statements).

Again, consider the same example: An online retailer allows customers to place and pay for orders. User authentication is a key security safeguard in this process.

• User authentication – The Web application requires users to authenticate with a username and password. The database should follow these rules for input validation:

o The database should allow the entire username and password listing to be returned to the Web application.

o The database should not allow mass updates of passwords.

SQL injection attacks have the potential to cause the following:

• Authentication bypass – This attack enables the attacker to gain access to the application without having to provide authentication information or to steal a legitimate user's authentication information.

• Information disclosure – This attack enables the attacker to view sensitive information stored in a database. Once the attacker gains access to the sensitive information, he or she may use it in an unauthorized manner. Sensitive information includes

o personal identification information–name, address, Social Security number, driver's license, passport number, and so on

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

o health information–medical history, prescriptions, and so on o usernames and passwords–authentication information that could be used to

assume the identity of an authorized user • Compromise of data integrity – If an attacker takes advantage of an SQL injection

vulnerability to assume administrative rights to the database, he or she can potentially modify data to corrupt its accuracy. An attacker could perform the following, for example:

o Web defacement–The attacker could modify the contents of the Web page just to boost his or her own notoriety or to communicate a political, religious, or ideological message.

o changing of prices in an online store–The attacker could modify the prices of items in an online store.

• Compromise of availability of data – This attack allows the attacker to delete information or portions of information with the objective of rendering the data inaccessible. In some cases, this method may be used to delete log or audit information–information that tracks user activity–contained in the database and thus remove evidence of the attack.

Figure 4.6 illustrates an SQL injection attack scenario.

Figure 4.6 SQL Injection Attack

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Business Logic Vulnerabilities

Business logic vulnerabilities are threats to the application that do not result from technical coding errors or deficiencies, but that are present as a result of incorrectly implemented business logic.

Many applications are designed to complete tasks associated with a business process. For example, a sales system application is a mechanism for storing customer contacts, placing new orders for the customer, maintaining order histories, and handling other business processes required of an organization's sales personnel. Such processes are referred to as business logic. A sales system might have the following business logic installed:

• Only regional sales managers have the ability to place orders for customers. • Orders cannot be placed between the hours of 5 p.m. and 5 a.m. • Orders in excess of $20,000 require review by another regional sales manager. • Orders of over 4,000 units require approval by the vice president. • No orders are accepted on the last day of the month. • Overseas orders are not permitted without approval by the vice president.

Whereas security threats such as cross-site scripting and SQL injection are introduced via broken or missing security controls (missing input validation, authentication, access control, etc.), business logic vulnerabilities stem from a missing or misunderstood business process. Business logic vulnerabilities may account for significant losses to an organization's operational effectiveness or revenue.

Integrating Security into the System Development Life Cycle (SDLC)

The system development life cycle is a process designed to ensure the successful management of information systems through their entire life span. (The abbreviation SDLC is also used to refer to the software development life cycle). Figure 4.7 represents the primary phases of the SDLC as defined by the National Institute of Standards and Technology.

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

Figure 4.7 SDLC Phases

Variations of SDLC methodologies are used in differing organizations and for differing types of systems development efforts (e.g. agile or extreme development methodologies). For the purposes of this course, we will focus on the traditional/linear SDLC model. The traditional SDLC model observes a linear phase progression. Each phase of the SDLC process is completed before the next phase is initiated. Regardless of the SDLC methodology used, most SDLC models have phases which are substantially similar to the core SDLC phases described above in figure 4.7.

Integrating Security into the SDLC

Many SDLC models did not include security as part of the development process. It has become necessary to include aspects of security in each phase of the SDLC process to ensure that security has representation and visibility throughout the entire life cycle of an information system. Implementing information security early in the life cycle allows the security requirements to develop in proportion to the system's operational requirements. Architecting security into a product's initiation phase typically costs less than acquiring technologies later that

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

may need to be reconfigured or modified, or that may provide more or fewer security controls than required.

Giving consideration to security up front when designing an information system could substantially reduce the need to add security controls later on. As an analogy, designing a car with two doors instead of four requires less point-of-entry security (fewer doors to protect), and wiring the car for an alarm and electricity at the same time excludes the need to rewire the car later.

Some benefits associated with early design and development of security controls include the following:

• Timely identification and mitigation of vulnerabilities – Early identification results in a lower cost of designing and implementing security controls.

• Awareness of security requirements early in the life cycle of the system – Those responsible for implementing the system can identify and test security requirements early on instead of discovering that the system fails to meet security requirements just before the system is to be implemented.

• Recycling of security solutions and technology – Once a secure solution to a problem has been developed and approved, that same solution can be recycled and reused in other information system projects.

• Executive insight for better security decision-making – The executive responsible for sponsoring/funding the information system's development will have a better appreciation of the security considerations associated with the system.

• Documentation of important security decisions during development – Considering security early in the process fosters continued confidence in the selection of security controls.

Each phase of the SDLC should have security considerations included to ensure that security is not an afterthought, implemented just before the system goes into operation. Below are specific security tasks that should occur during each phase of the SDLC.

Phase 1: Initiation • Implement security training – Security training is a necessary part of the initiation of a

project. If the personnel responsible for the development of the system are not adequately trained in secure development processes, they might introduce vulnerabilities into the system due to a lack of knowledge of proper security design. It is best to provide training before development/acquisition begins. The more the

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

developer knows about how security and security measures are built into the system, the more secure the system will be.

• Assign security responsibility – For a new system to succeed from a security perspective, it must have a person (or persons) responsible for the security of the system throughout its life cycle. This person may be given the title information system security officer (ISSO), business security officer (BSO), or any other formal designation conferred by the organization. Regardless of the title, the person identified as responsible for the security of the system should advocate security measures and insist on security methodologies throughout the system's life cycle.

• Conduct an initial security categorization of the information system – As the system is conceptualized and undergoing an initial description with requirements documented, it is important to establish the security categorization of the system. As we discussed in module 1, a system can be categorized according to the sensitivity of the information it stores, transmits, or receives. For instance, a system of the U.S. government can have a secret designation associated with it. The ISSO of such a system will have to design security controls to support a system in this category.

• Conduct an initial documentation of security requirements – A key concept of secure SDLC is the formal documentation of all planned and implemented security controls. Documentation of these controls should begin as soon as the project is initiated. This ensures that the required security controls will be considered during future phases of the SDLC.

Phase 2: Development/Acquisition • Design security architecture – The design of the system's security architecture is an

important component of the SDLC. The system architect will examine the system security requirements then select security controls and specify how those controls will be built into the system in order to meet the stated requirements. For federal government IT systems, these requirements are derived from FIPS 199 Standards for Security Categorization of Federal Information and Information Systems, FIPS 200 Minimum Security Requirements for Federal Information and Information Systems, and NIST SP- 800-53 Security and Privacy Controls for Federal Information Systems and Organizations.

• Perform functional security testing – As components of the system are completed, security testing of each functional component should be performed. For example, if it was determined that users would access the application using strong passwords, the security representative could perform testing of strong passwords when that component was complete by verifying that proper password length was in place, password complexity requirements were enforced, and so on.

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

• Prepare documents for system certification – Before a system is to be implemented, it should be certified by the system's sponsor (sometimes referred to as the system owner). Certification involves formally reviewing all existing security controls associated with the information system. Security controls are the mechanisms in place to secure the system. For instance, having the system require passwords is a security control.

Phase 3: Implementation/Assessment • Review all existing documentation – Existing documentation must be reviewed to ensure

that all security controls have been appropriately identified and integrated into the system.

• Gain executive approval – As mentioned above, the implementation phase requires formal approval of the executive sponsor of the system.

• Enact a secure deployment – The deployment/implementation of the information system must be performed in a manner that does not reduce the effectiveness of the security controls. For instance, if the information system needs to be configured to restrict access to the Internet, that condition must be part of a deployment checklist, which will ensure that as the system moves into a usable state, it is not deployed in an insecure manner.

Phase 4: Operation/Maintenance • Manage secure configuration – Once the system is moved into operation, it is imperative

that the configuration of the system be kept secure through management and observation. Again, the concern is that, even if the system was designed with security in mind, if it is in operation for an extended period of time, its security controls could erode.

• Continuously monitor security controls – Once the security controls for the system are designed, it is necessary to ensure that they remain effective. This may involve continued and ongoing testing of security controls to verify that the system has not been configured in a manner that reduces its ability over time to protect information.

• Maintain documentation – Inevitably, the system's security controls will evolve as the system is used. This evolution may be necessary for the accommodation of new functionality or for the implementation of new and more stringent security controls. As the system changes over time, it is necessary to maintain and update the documentation that describes the way the controls protect the information system and its data.

Phase 5: Disposal • Archive or transition data as necessary – Depending on the requirements of the system, it

may be necessary to archive, or to create backups of, the data once the system is no longer operational. If the system is being replaced by a newer system, it may be necessary to transition data from the legacy (older) system to the newer system.

• Securely wipe media – When media (hard drives, thumb drives, and so on) are no longer required for the operation of the system, the data on these devices must be erased in a

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

manner that ensures that the data is not recoverable. This applies even if the power has been removed from the drive for an extended period of time.

• Erasing media is referred to as wiping media, as you are essentially wiping data from the devices. Wiping media may involve writing garbage data to the drive over and over to prevent the drive from retaining any meaningful data.

• Dispose of hardware/software – After the media have been appropriately wiped, they can be securely disposed of. In some cases, this means that the hardware (servers, desktops, laptops, etc.) must be completely physically destroyed or incinerated.

Acknowledgements

This material was adapted from CSIA 301 Course Module #4: Secure Development of Applications and Systems.

CSIA 360 Cybersecurity in Government Organizations

Copyright 2015 by University of Maryland University College. All Rights Reserved.

References

Grossman, J. (2010, September 23). Website security statistics report (2010)–Industry benchmarks. Retrieved December 14, 2010, from http://jeremiahgrossman.blogspot.com/2010/09/Web site-security-statistics-report- 2010.html

Kissel, R., Stine, K., Scholl, M., Rossman, H., & Fahlsing, J. (2008). Security considerations in the system development life cycle (NIST SP 800-64) (revision 2). Gaithersburg, MD: National Institute of Standards and Technology. Retrieved July 7, 2015 from http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf

Miller, R. (2010, June 28). Facebook server count: 60,000 or more. Retrieved July 7, 2015 from http://www.datacenterknowledge.com/archives/2010/06/28/facebook-server-count- 60000-or-more/