Start Secure. Stay Secure.TM

Building Web Application Security into Your Development Process
Are your web applications vulnerable?
By Kevin Heineman

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Table of Contents
Introduction Thinking of Security as a Process The Development Life Cycle Defining Secure Requirements Application Security as Part of Analysis and Design Coding for Web Application Security Secure Coding Practices Designing Secure User Interfaces Prototyping Security into Your Application Testing with Security in Mind Deploying Secure Applications Security in a Post-Implementation Environment Conclusion The Business Case for Application Security About SPI Labs About SPI Dynamics About the WebInspect Product Line About the Author 1 4 5 6 8 13 14 15 15 16 17 18 18 20 20 20 21 22

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. ii

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Introduction
Information security is an ever-evolving process. Change began when companies realized that electronic information is a corporate asset and needs to be protected just like any other. Companies started protecting their information by using firewalls to protect their networks. Security then progressed as companies implemented Intrusion Detection Systems (IDS) to monitor network traffic. Information security has evolved from network and server layers and now includes the Web application layer. Many companies are unaware that their corporate assets are exposed even though they have implemented firewalls and IDS. In part, this is due to the fact that organizations have not yet incorporated Web application security into their development processes. The evidence is significant. An estimated 70 percent of all security breaches today are due to vulnerabilities within the Web application layer. The New York Times and eBay have both recently publicized security breaches on their Web sites. In each incident, the attacker used the Web application to gain access to confidential information. On the New York Times Web site, hackers were able to obtain confidential donor information including Social Security numbers and donation amounts. On eBay, hackers successfully stole user names and passwords, and then stole customer credit card information by setting up fraudulent auction sites that carefully mimicked eBay's own site. These two well-publicized events demonstrate the power of application-level attacks and confirm how Web applications are vulnerable even with proper firewall and IDS protection. Why is this problem so widespread? What can be done about it? The answer lies in looking at security, not just from an operations perspective, but as an integral part of the entire development lifecycle.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 1

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Security must be built into the Web application development process itself. Over the past decade, a significant amount of human capital has been spent touting the benefits of structured development processes. It has become common industry understanding that strong, repeatable development processes produce better quality code in less time than unstructured processes. This theory argues that development efficiency and effectiveness is gained by perfecting a process through practice. However, the adage "Practice makes perfect" is true only if a person practices correctly. Nobody will learn to be a good speller through practice if they continually practice spelling words wrong. The same is true for application development. A structured, repeatable development process will produce a superior product only if it systematically covers all aspects of application development. Development processes that neglect any facet of application development will produce a substandard product and could result in poorly architected applications. Even in mature development organizations, one of the most commonly overlooked areas of the application development process is Web application security. This oversight is primarily for three reasons. First, the methodology of Web application security is relatively new and unknown in the market. Security has traditionally been focused on the network and server layers of an application's architecture. However, even architectures that have secure network and server layers are exposed to attacks if the application layer is insecure. Secondly, development tools such as Microsoft's Visual Studio, BEA's WebLogic, and Macromedia's ColdFusion provide powerful development environments that greatly improve development productivity. However, these

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 2

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

environments require careful configuration to ensure that only the appropriate services are running in the production environment. Unfortunately, many development shops neglect to configure the production environment properly, which leaves the Web applications vulnerable. Finally, developing secure Web applications is usually an afterthought for most organizations. Since security is not directly related to functional requirements, users do not focus on it and developers generally fail to put in the necessary time to ensure that Web applications are secure. In addition, some developers do not feel that application security is necessary. They feel that if they use IIS or implement their applications behind a firewall, they will be secure from malicious attacks. Even developers who do see the importance of Web application security usually view it as task that is performed as part of the QA process. As a result, many Web applications may be functionally rich, but still vulnerable to unwanted intrusions and attacks at the application layer. Furthermore, many development organizations view security as an event to be completed only once during the development process. In these cases, security becomes the responsibility of a single organization such as the Quality Assurance or Internal Audit departments. Once these departments sign off on an application, it is deemed secure by the organization. However, Web applications are not static systems. Changes to Web applications create risks; what was once secure is now vulnerable. If security is viewed as a single event, a vulnerability that enters the system after the audit will go undetected. Web application security does not need to be an oversight, afterthought, or viewed as an event. Rather, it should be viewed as a process and incorporated throughout the development life cycle to ensure Web

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 3

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

applications are built securely. It should be incorporated into the practices of every team member associated with the development and operations of the Web application. In this white paper, we will describe how to incorporate Web application security development practices into a typical object-oriented development process. Examples within this white paper will incorporate many of the common models within the Unified Modeling Language (UML). However, these practices are generic in nature and could be incorporated into any structured development process.

Thinking of Security as a Process
Thinking of security as a process that should be addressed throughout the development life cycle is a paradigm shift for many development organizations. While many organizations claim that they view security as a process, in reality security is not usually given the due process it requires. For example, the extent of security requirements gathering for many organizations is limited to the technical requirements section of the requirements document. The extent of detail allocated to security requirements is commonly limited to high-level requirements like "Develop the product using IIS." This level of detail does not provide developers with the guidance they need to develop applications securely. The result of this approach relegates security requirements to second-class status and they become a task for the operations department to complete as part of deployment. For security to be appropriately addressed as part of the development process, it needs to be consciously addressed throughout the development life cycle. This includes defining security as part of both the functional and technical requirements of an application. Once requirements are completed, security should be modeled as part of the analysis and design of the

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 4

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

application. Secure coding practices will then ensure the application is built in a secure manner. QA should build and execute its test plan with security specifically targeted and the application must be deployed in an environment that has been hardened for security. Once deployed, periodic security audits in the production environment will ensure the application remains secure as it is updated. This is the process of Web application security. The remaining sections of this paper describe each phase of the application development life cycle and describe how Web application security should be incorporated into it.

The Development Life Cycle
To describe the process of Web application security, it is first important to define common development methodology terms and processes. All development methodologies can be abstracted to a level of commonality. This point of commonality generically includes the following phases: requirements gathering, analysis and design, development, quality assurance, deployment, and post deployment. The following diagram depicts this methodology.

Figure 1: Development Life Cycle Methodology Commonalities. Whether an organization's development process uses extreme programming (XP), iterative, waterfall, or some other derivative, each methodology will contain tasks that can be mapped to these phases. While different methodologies may use different phase names and the number of phases may vary, the type of work will be the same. For the purpose of this paper,

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 5

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

these generic phases will be used to describe how security should be incorporated into the process.

Defining Secure Requirements
The process of securing Web applications must begin in the requirements gathering phase. A common practice in gathering requirements is to develop Use Cases that describe the functional process of a system. Use Cases are normally developed in coordination with functional experts as a way to describe how the system will work. Use Cases describe the proposed system's business processes and detail the steps the system will perform to complete those processes. Use Cases also describe how external entities (actors) will interact with the system. As part of Use Case development, security should be viewed as a business process and modeled appropriately. Each Use Case should contain information that answers the question "What process ensures that corporate assets and customer information is secure?" This may include steps within a Use Case or it could be abstracted into a separate Use Case for clarification and reuse purposes. For example, a Web application that contains functionality for customers to perform online transactions would contain the ability for a customer to purchase a product online. To simplify this example, the system will contain one primary Use Case, Purchase Product. As part of the purchasing process, the customer will need to be authenticated to ensure the customer is a valid customer. Authentication is a form of application security that can be modeled as a process. Authentication could be as simple as validating a user name and password, or as complex as a validation with multiple levels of security including timed entry processes. It is important that the requirements adequately describe the level of detail that is required for this

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 6

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

process. The following diagram graphically depicts this simple system as a Use Case model of a customer purchasing a product.

Figure 2: Use Case Model of an Online Checkout System. The Use Case should also explain what the system should do in the event that the user is not authenticated. Modeling application security using Use Cases will educate the end users as to the importance of the security within the application. It will also provide specific direction for developers to eliminate many assumptions during the development process. In addition to modeling the security processes, business rules that further define application security should also be developed. Business rules are functional aspects of the system that cannot be modeled as a process. An example of a business rule may be that passwords expire after account inactivity of six months. These business rules can be documented in the Use Case itself or separately, depending on the requirements definition practices of the development organization. However they are captured, practices need

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 7

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

to be implemented to manage business rules as part of the overall requirements gathering process. Application security requirements should not be limited to functional requirements, but should also be developed as part of the technical requirements. Technical requirements define the features of the system that are not user defined. This includes requirements such as server configuration, capacity, performance, scalability, and security. Technical requirements that define application level security should focus on items that will help protect the application from intrusive forms of attacks. Examples of these types of requirements include: A session should time out after 10 minutes of inactivity requiring the user to log back into the application. All incoming data must be validated for proper format before processed by the system. Only Port 80 will be left open on production Web servers. Documenting technical security requirements will help ensure that security is included in subsequent phases of the development life cycle.

Application Security as Part of Analysis and Design
Web Application analysis and design includes developing class diagrams and interaction diagrams. While other diagrams such as state transition and component diagrams are also built during this phase, the class diagram and interaction diagram are the primary models. Analysis and design models are developed to describe the logical and physical interactions between the

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 8

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

objects of the system. The class diagram depicts all the objects of the system and describes the interactions between them. Interaction diagrams are commonly called sequence diagrams and depict how objects interact to complete a specific function of the system. The functions modeled are generally Use Cases but could also be infrastructure or foundation interactions. To ensure application security is considered, security should be specifically addressed within each of these models. Ideally, development organizations should address security as independent objects within the model. Continuing the Online Checkout System example, developing security into the class diagram would look as follows:

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 9

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Figure 3: Security Classes. In this model, the customer and the product interact with the shopping cart to complete a transaction. If security were not addressed, the model would be complete. However, the Security object plays an important role in this system. The Security objects contain the attributes and methods that are called to prevent malicious attacks into the system. For example, the SQL Injection Policy will block inputs that do not conform to the policy, thus preventing this type of attack against the Shopping Cart object. Modeling security explicitly is a good practice to help ensure that the appropriate security questions are addressed during this phase of the project.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 10

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Another important analysis model is the interaction diagram. This model describes how objects interact to complete the process flow within a Use Case. It is the link between the functional Use Case and the objects of the system. Security may be modeled several different ways within this model depending on how it was modeled in the Use Case and class diagram. If security is modeled as a Use Case, an individual interaction diagram will be created to model it. Security objects will be modeled as fence posts within each diagram that requires them. Also, individual steps within Use Cases that describe security will be modeled as line items within the interaction diagram. Continuing the Online Checkout example, the following interaction diagram displays how the objects interact to complete the checkout process.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 11

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Figure 4: Online Checkout Security Interaction. In this example, security is modeled both as a fence post object and a step within the process. The fence post objects performs the security checks modeled in the class diagram while the steps are the steps modeled within the Use Case diagram. Once these models have been diagramed, the system is ready to be coded. Up to this point in the development process, building security into a Web application involves expanding an organization's current development

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 12

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

process to include Web application security. Existing toolsets should be able to support the additional processes needed to capture the necessary requirements and conduct the appropriate analysis and design security modeling. However, the remaining development lifecycle phases will require additional tools to ensure that Web applications are constructed and implemented securely. The primary tool to support this process is a Web application assessment tool such as SPI Dynamic's WebInspect. WebInspect facilitates the simulation of an advanced Web application attack. It can be used by developers, QA testers, and operations administrators to pinpoint specific Web application vulnerabilities in their Web sites. The results can be proactively cycled back through the development process to ensure that vulnerabilities are corrected and risks are mitigated. The following sections describe how to construct and implement secure Web applications. It is assumed that an organization is utilizing a tool like WebInspect to get maximum protection of its Web applications.

Coding for Web Application Security
Developing secure requirements and modeling security as part of analysis and design provides direction for the developer when it comes time to code the application. However, if an application is not built securely, it doesn't matter how well the requirements were defined or the system was modeled. Ensuring an application is built securely involves developing and enforcing secure coding practices. It is important to note that secure coding practices include not just the application code, but also other aspects of development such as User Interface (UI) development and prototyping.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 13

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Secure Coding Practices
Most organizations have at least a minimal amount of coding standards such as naming conventions and documentation requirements. Adding security to standard coding practices can provide an organization with immediate payback in terms of producing more secure applications. Examples of these practices include: Never trust incoming data to the system and apply checks to this data. Never rely on the client to store sensitive data no matter how trivial. Error messages must be generic to the user but documented for support purposes. Use object inheritance, encapsulation, and polymorphism wherever possible. Use environment variables prudently and always check boundaries and buffers. Once secure coding practices are established, they must be enforced. The primary method is the code walkthrough, where one developer (preferably a senior developer) reviews code written by another developer. The reviewer generally audits the code from the perspective of security to ensure it conforms to the organization's generally accepted coding standards. Code that does not conform to the security standards must be corrected before it is passed into the testing cycle.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 14

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Organizations that follow iterative development or XP methodologies can perform these practices very quickly. Within these methodologies, developers are teamed in pairs to develop a function. Each developer should audit and review their partner's code from a security perspective. This practice will tighten security procedures and reduce the vulnerabilities that pass into the testing process.

Designing Secure User Interfaces
Secure user interface design should be careful about the type of data that the user is able to access. Limits should be built into the application to restrict the data that can be entered into form fields. In addition, fields should be restricted to the type of information that can be entered. For example, domestic ZIP codes should be limited to numeric values only. Once the interface is designed, developers should walk the users through the interface from a security perspective, focusing on what the user should and should not be able to do. The results of this walkthrough should be compared with the requirements, analysis and design models, and code to determine if the system supports the appropriate user actions and prevents actions that are not authorized. This iterative process will help identify vulnerabilities and close them before the system is released in production.

Prototyping Security into Your Application
Prototyping is a key component of iterative Web development and is useful in breaking down complex modules or conducting proof of concepts for specific functionality. Unfortunately, too often a prototype is put into production and becomes a support nightmare. Prototypes are not intended for production environments. By their nature, prototypes generally do not contain the infrastructure required of a production system. Security is usually one of those infrastructure items that are not incorporated into a prototype.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 15

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Organizations should implement practices to prevent prototypes from being released into production unless the prototype is enhanced to a minimum set of infrastructure requirements. Adequate application security must be one of these minimum requirements. In addition, the practice of auditing all production applications for security vulnerabilities should be implemented to ensure that applications with security problems are identified quickly.

Testing with Security in Mind
Testing is a process that begins early in the software development life cycle and extends until deployment. Quality Assurance testers ensure that the application works according to the requirements, but some requirements may be implied or undocumented, even in mature development organizations. Because security, in particular, is often slighted, testers are the last line of defense between a potential security problem and the assets of the company. QA testers must always have security in mind and be very skeptical of the thoroughness of application security within the system. The first step of security testing is to build security into the test plan. Security should be included as a unique section so that it gets the necessary attention during the QA process. While traditional system testing ensures the application performs its required functions, security testing ensures that the application does not perform certain functions. Security scenarios should be developed that define potential malicious attacks against the system, such as brute-force hacking, parameter checking, SQL injection, buffer overflows, and cross-site scripting. Each scenario should outline a plan of attack that a malicious intruder would take to compromise the application. Once the test plan is complete, test cases should be defined to test the methods that attackers use to break applications. The test cases should describe the action that will be tested, the expected result, and whether or not the test passed

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 16

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

the test. It is critical that security testing is completed during the QA phase, before the system moves into production.

Deploying Secure Applications
Even after an application has passed QA, it still could be vulnerable to malicious attacks if the application is deployed in an insecure environment. Therefore, security checks should be applied to the production environment to ensure the production servers are set up securely. Some of the primary procedures that should be included are: Develop a backup and recovery plan. Limit access to the server and regularly change administrator passwords. Ensure all Web server ports are closed except the ones that are needed for the application running on the server. Ensure the network connections with other servers and other networks are properly defined and secured. Make sure OS patches are applied to the server on a regular basis. Do not leave extraneous files with old file extensions on any Web server available to the public. Identify only essential services for the Web server and eliminate others. These procedures should be developed and maintained for a production environment and then periodically audited to ensure they are followed.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 17

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Security in a Post-Implementation Environment
Web applications by their nature are not static. Content is altered and new features are added, in some instances on a continual basis. Each time the Web application is changed, a risk is imposed that the application will not be secure. Even the simplest of changes could produce a vulnerability that could pose a major threat to the assets of the company or, just as important, information about a company's customers. However, adding the overhead of a full QA security test could bring many development organizations' deployment plans to a halt, defeating the purpose of rapid Web application development. Therefore, by including the proper security checks and balances in all aspects of the development process and maintaining a constant mindset toward security, a development organization minimizes its risk of deploying applications with security vulnerabilities. Still, security vulnerabilities may creep into an application even in the most secure organizations. To mitigate this risk, periodic random penetration testing should be conducted against the Web application server farm. It is important to note that this testing should be conducted by an independent third party who does not have a vested interest in the development or deployment of the application.

Conclusion
Companies need to view their Web applications as a portal to corporate assets and therefore need to implement the necessary security procedures to ensure that those assets are secure from malicious attacks. Security has evolved from the network layer to the server layer and now includes the application layer. All these layers need to be protected to ensure secure Web applications. Incomplete development processes leave the applications at risk, no matter how structured the company's development process may be.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 18

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

To achieve a greater level of application security, mature development practices that focus specifically on Web application security need to be implemented. We have demonstrated the need for secure practices within the development process and have shown how these practices could be incorporated into a common development methodology. Using a few of these concepts and incorporating them into an existing methodology will provide immediate payback and better quality applications.

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 19

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

The Business Case for Application Security
Whether a security breach is made public or confined internally, the fact that a hacker has accessed your sensitive data should be a huge concern to your company, your shareholders and, most importantly, your customers. SPI Dynamics has found that the majority of companies that are vigilant and proactive in their approach to application security are better protected. In the long run, these companies enjoy a higher return on investment for their ebusiness ventures.

About SPI Labs
SPI Labs is the dedicated application security research and testing team of SPI Dynamics. Composed of some of the industry's top security experts, SPI Labs is focused specifically on researching security vulnerabilities at the web application layer. The SPI Labs mission is to provide objective research to the security community and all organizations concerned with their security practices. SPI Dynamics uses direct research from SPI Labs to provide daily updates to WebInspect, the leading Web application security assessment software. SPI Labs engineers comply with the standards proposed by the Internet Engineering Task Force (IETF) for responsible security vulnerability disclosure. SPI Labs policies and procedures for disclosure are outlined on the SPI Dynamics web site at: http://www.spidynamics.com/spilabs.html.

About SPI Dynamics
SPI Dynamics, the expert in web application security assessment, provides software and services to help enterprises protect against the loss of confidential data through the web application layer. The company's flagship product line, WebInspect, assesses the security of an organization's applications and web services, the most vulnerable yet least secure IT

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 20

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

infrastructure component. Since its inception, SPI Dynamics has focused exclusively on web application security. SPI Labs, the internal research group of SPI Dynamics, is recognized as the industry's foremost authority in this area. Software developers, quality assurance professionals, corporate security auditors and security practitioners use WebInspect products throughout the application lifecycle to identify security vulnerabilities that would otherwise go undetected by traditional measures. The security assurance provided by WebInspect helps Fortune 500 companies and organizations in regulated industries -- including financial services, health care and government -- protect their sensitive data and comply with legal mandates and regulations regarding privacy and information security. SPI Dynamics is privately held with headquarters in Atlanta, Georgia.

About the WebInspect Product Line
The WebInspect product line ensures the security of your entire network with intuitive, intelligent, and accurate processes that dynamically scan standard and proprietary web applications to identify known and unidentified application vulnerabilities. WebInspect products provide a new level of protection for your critical business information. With WebInspect products, you find and correct vulnerabilities at their source, before attackers can exploit them. Whether you are an application developer, security auditor, QA professional or security consultant, WebInspect provides the tools you need to ensure the security of your web applications through a powerful combination of unique Adaptive-AgentTM technology and SPI Dynamics' industry-leading and continuously updated vulnerability database, SecureBaseTM. Through

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 21

Start Secure. Stay Secure.TM Building Web Application Security into Your Development Process

Adaptive-Agent technology, you can quickly and accurately assess the security of your web content, regardless of your environment. WebInspect enables users to perform security assessments for any web application, including these industry-leading application platforms: Macromedia ColdFusion Lotus Domino Oracle Application Server Macromedia JRun BEA Weblogic Jakarta Tomcat

About the Author
Kevin Heineman, vice president of engineering at SPI Dynamics, has more than 11 years of successful management and consulting experience in information technology and product development organizations. Prior to SPI Dynamics, he was the director of e-commerce software development at Worldspan. He also spent eight years as a consultant for companies such as Ernst & Young and American Management Systems.

Contact Information
SPI Dynamics 115 Perimeter Center Place Suite 1100 Atlanta, GA 30346 Telephone: (678) 781-4800 Fax: (678) 781-4850 Email: info@spidynamics.com Web: www.spidynamics.com

© 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 22