Complete Web Application Security. Phase1-Building Web Application Security into Your Development Process

Transcription

1 Complete Web Application Security Phase1-Building Web Application Security into Your Development Process

2 Table of Contents Introduction 3 Thinking of security as a process 4 The Development Life Cycle 6 Figure 1 Development Life Cycle Methodology Commonalities 6 Defining secure requirements 6 Figure 2 Use Case Model of an Online Checkout System 7 Application security as part of analysis and design 8 Figure 3 Security Classes 8 Figure 4 Online Checkout Security Interaction 9 Coding for Web Application Security 10 Secure Coding Practices 10 Designing secure User Interfaces 11 Prototyping security into your application 11 Testing with security in mind 12 Deploying secure applications 12 Security in a post implementation environment 13 Conclusion 13 About SPI Dynamics 14

3 Introduction Building Web Application Security into Your Development Process 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% 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 illegally obtain confidential donor information including Social Security numbers and donation amounts through the Web application. 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 demonstrated the power of application level attacks and confirmed how vulnerable Web applications are even with proper firewall and IDS protection. So 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. 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 old adage, Practice makes perfect is only true 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 Page 3

4 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. Second, development tools like IBM s Websphere, BEA s WebLogic, and Macromedia s Cold Fusion provide powerful development environments that greatly improve development productivity. However, these environments require careful configuration to ensure 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 development 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 once during the development process. In these cases, security becomes the responsibility of a single organization like 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 so that what was once secure is now vulnerable. If security is viewed as a single event, a vulnerability that enters the system after the audit is performed 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 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 Page 4

5 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. In order 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 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. This paper has introduced the concept that application security should be viewed as a process, not an event or task. The remaining sections of this paper will describe each phase of the application development life cycle and describe how Web application security should be incorporated into it. Page 5

6 The Development Life Cycle In order 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 utilize different phase names and the number of phases may vary, the type of work will be the same. For the purpose of this paper, these generic phases will be utilized 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 process. The following diagram graphically depicts this simple system as a Use Case model of a customer purchasing a product. Page 6

7 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 6 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 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 only. Application security 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 like 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. Page 7

8 Application security as part of analysis and design Web Application analysis and design includes developing class diagrams and interaction diagrams. While other diagrams like 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 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: 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 Page 8

9 ensure that the appropriate security questions are addressed during this phase of the project. 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. 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 mo deled 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. Page 9

10 Up to this point in the development process, building security into a Web application involves expanding an organization s current development 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 that will support this process is a Web application assessment tool like 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 that are contained within 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 like User Interface (UI) development and prototyping. Secure Coding Practices The spectrum of different types of coding practices is only eclipsed by the number of software developers in the world. Coding practices within an organization can run from none to strict adherence to coding practices. Most organizations have at least a minimal amount of coding standards like 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. Utilize object inheritance, encapsulation, and polymorphism wherever possible. Use environment variables prudently and always check boundaries and buffers. This list is a small set of potential practices. Coding practices can be platform and language specific. Organizations should make a conscious effort to develop the appropriate practices for their organization. Page 10

11 However, establishing secure coding practices is only half the battle. Enforcement of these practices must also be put in place in order to ensure that secure coding practices are being followed. Enforcement can be completed a number of ways, the primary of which is through code walkthroughs. Code walkthroughs usually involve a senior developer, or a developer who was not involved in writing the code, reviewing code written by another developer. The reviewer generally reviews or 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. Organizations that follow iterative development or XP methodologies have the ability to 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 designed, a practice of walking the users through the interface from a security perspective should be established. This walkthrough should focus 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 was developed to support the appropriate user actions and prevent 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 to 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, becomes a product, and subsequently 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. 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. Page 11

12 Testing with security in mind Testing is a process that begins early in the software development life cycle and extends until deployment. It is the responsibility of the Quality Assurance testers to ensure that the application works according to the requirements. However, even within mature development organizations, some requirements may be implied and undocumented. Security, in particular, is often left out of requirement documentation. As a result, testers cannot rely that all security requirements are documented and must act as 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 looks at testing from a different angle. Security testing ensures the application does not perform certain functions. Security scenarios should be developed that define potential malicious attacks against the system. These scenarios should include items like brute force hacking, parameter checking, SQL injection, buffer overflows, and cross-site scripting, to name a few. 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 the test. It is critical that security testing is completed during the QA phase because once the QA phase is complete, 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. Page 12

13 Security in a post implementation environment Web applications by their nature are not static. Content is continually being 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. This would defeat the purpose of rapid Web application development. Therefore, by including the proper security checks and balances in all aspects of the development process and 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 for the purpose of finding Web application security vulnerabilities that may have slipped through the testing process or may have been inadvertently applied through changes to the production environment. 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 corporate 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 that companies deploy at risk no matter how structured their development process may be. In order 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. Page 13

14 About SPI Labs SPI Labs is the dedicated application security research and development team of SPI Dynamics. Comprised of some of the industry s top security experts, SPI Labs is focused specifically on researching security vulnerabilities at the Web application layer. SPI Labs mission is to provide objective research to the security community and all organizations concerned with their security practices. About SPI Dynamics SPI Dynamics provides software that protects against the loss of confidential data through the organization s most vulnerable yet least secure infrastructure component the Web application layer. Software developers, quality assurance professionals and security practitioners use SPI Dynamics Adaptive-Agent technology to discover application vulnerabilities that would otherwise go undetected using traditional network firewalls and intrusion detection systems. About WebInspect WebInspect ensures the security of your entire network with innovative, easy-touse and automated processes that dynamically scan standard and proprietary Web applications to identify known and unknown application vulnerabilities. WebInspect provides a new level of protection for your critical business information. With WebInspect, you find and correct vulnerabilities at their source, before attackers can exploit them. Whether you are a Web 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-Agent technology and SPI Dynamics' industry leading and continuously updated vulnerability database, SecureBase. SPI Dynamics 115 Perimeter Center Place Suite 270 Atlanta, GA Telephone: (678) Fax: (678) [email protected] Web: Page 14