Securing Enterprise Web Applications at the Source: An Application Security Perspective Author: Eugene Lebanidze [email protected] EXECUTIVE SUMMARY Purpose: This paper considers a variety of application level threats facing enterprise web applications and how those can be mitigated in order to promote security. Evidence shows that perhaps as many as sixty percent of attacks on enterprise web applications are facilitated by exploitable vulnerabilities present in the source code. In this paper we take the approach of examining the various threats specific to the application layer along with their corresponding compensating controls. Threats specific to each of the tiers of the n- tiered enterprise web application are discussed with focus on threat modeling. Compensating controls are addressed at the architecture, design, implementation and deployment levels. The discussion focuses around the core security services, namely confidentiality, integrity, authentication, authorization, availability, non-repudiation and accountability. The paper examines how these core security services are supported in the J2EE and .NET frameworks. Recommendations and standards from various organizations are considered in this paper (e.g. OWASP, NIST, etc.) We also recognize that development and deployment of a secure enterprise web-based application is dependent upon the organization’s enterprise security architecture (ESA) framework. Therefore, we map some elements of our discussion for security architecture and technology issues to the five rings of the enterprise security architecture model, particularly in the context of the Zachman Framework enterprise architecture (EA). While most of the web application security threats and mitigations discussed fall in rings four and five, we tie the local risk to the enterprise risk in ring one of the ESA. In this discussion we draw from the NIST special publications SP800-37 (“Guide for the Security C&A of Federal Information Systems) [20], SP800-64 (“Security Considerations in the Information System Development Life Cycle”) [16], SP800-53 (“Recommended Security Controls for Federal Information Systems”) [15], and SP800-26 (“Security Self- Assessment Guide for Information Technology Systems”) [14]. Security Criteria: The security criteria for evaluation of web application security revolve around the core security services collectively known as CI4A (Confidentiality, Integrity, Authentication, Authorization, Availability, Accountability). Non-repudiation is another security service commonly tied with accountability. In the context of enterprise web applications, confidentiality is concerned with the privacy of information that passes through or is stored inside the web application. Integrity ensures that the data used is free from deliberate or accidental modification. Authentication addresses verification of identities. Authentication can also be thought of in the context of source integrity. Authorization focuses on access rights to various application subsystems, functionality, and data. Availability, an often ignored aspect of security, is nevertheless an important metric for the security posture of the web application. Many attacks that compromise application availability exploit coding mistakes introduced at the application source level that could 2 have been easily avoided. Non-repudiation addresses the need to prove that a certain action has been taken by an identity without plausible deniability. Accountability, tied with non-repudiation, allows holding people accountable for their actions. There are a variety of known vulnerabilities that can be exploited in web applications to compromise the core security services outlined above (CI4A). While a provision of a complete taxonomy of attacks would be impractical, if not impossible, especially in light of an ever increasing ingenuity exhibited by hackers (not to mention a growing arsenal of hacking tools), it makes very good sense to consider the classes of vulnerabilities that a web application can contain that could be exploited by attackers to compromise CI4A. Having those classes of vulnerabilities in mind helps structure an assessment of application security and more importantly helps focus security analysis across all stages of application development, including requirement specification, architecture, design, implementation, testing, etc. One organization took the initiative to provide the top ten classes of vulnerabilities that plague modern enterprise web applications that have the greatest impact on CI4A. The Open Web Application Security Project (OWASP) has recommended the top ten list of application level vulnerabilities in web applications that make for a very useful security criteria compliance metrics. The top ten classes of vulnerabilities outlined by OWASP are: unvalidated input, broken access control, broken authentication and session management, cross site scripting (XSS) flaws, buffer overflows, injection flaws, improper error handling, insecure storage, denial of service and insecure configuration management [24]. Each of these is discussed in great detail subsequently in this paper. We also consider the various security criteria for certification and accreditation (C&A), as outlined in NIST SP800-37 (“Guide for the Security C&A of Federal Information Systems”) as they apply to development of enterprise web-based application. Certification analyzes risks local to the web application, such as potential vulnerabilities present in the source code and the corresponding compensating controls (Rings 4-5 of the ESA). On the other hand, accreditation focuses on enterprise level risks that may result from vulnerabilities found in a web-based enterprise application. Additional security criteria can be gathered from SP800-53 (“Recommended Security Controls for Federal Information Systems”) and SP800-26 (“Security Self-Assessment Guide for Information Technology Systems”). Secure enterprise web-based applications and their supporting technologies should follow the recommended security controls in SP800-53. Scope and Limitations: One of the most prevalent concepts in security is the defense in depth principle. This principle dictates that there should be multiple levels of protection to protect critical assets. The focus of this paper is on security of enterprise web applications from the perspective of application security. There are certainly other perspectives from which web application security could and should be evaluated. For instance, network security and host security also play a critical role. However, this paper focuses on application security because of the special significance that this security layer has come to play. Many attacks on corporate applications come form inside the network, thus rendering 3 such protection mechanisms as firewalls useless. Additionally, intrusion detection techniques will not work when the problem is poor input validation in the application. The point is that network and host security can often help fight the symptoms of the problem where the source of the problem is in the application source. This paper also discusses the architecture, design and deployment considerations that have security implications. It is often suggested that security is a process and not a product. We certainly believe that to be true since most secure software is the result of security aware software development processes where security is built in and thus software is developed with security in mind. In other words, throughout the various stages of the Software Development Lifecycle (SDLC), software project members are responsible for performing security related activities and producing/consuming security artifacts in order to provide a more structured approach to application security. Automation of source code analysis for security vulnerabilities should also be applied as part of any secure development process. We are omitting the discussion of security process in this paper due to time constraints, but it is implied that developers who apply secure coding techniques that we describe in this paper when developing secure enterprise web-based applications should operate in the context of a secure software development process. To learn more about integrating security in the SDLC please refer to the Comprehensive Lightweight Application Security Process (CLASP) authored by John Viega and available free from Secure Software (www.securesoftware.com) [11]. A secure development process should also incorporate C&A (NIST SP-800-37), various process level security controls (NIST SP-800-53) and contain various metrics for security self- assessment described in NIST SP-800-26. Additionally, a secure process will be part of the enterprise security architecture where both local risk (Rings 4-5) and enterprise risks (Ring 1) are mitigated. Summary of Conclusions: We conclude that J2EE and .NET platforms both have fairly comparable security models that provide extensive support for all of the core security services. Throughout this paper, as we discuss many of the specific compensating controls, we very often come back and tie our discussion to the key security principles. We cannot emphasize enough how critical it is for all members of the software project team to be familiar with and follow these principles because only solutions that comply with these principles will have any chance of providing true protection for the core security services. We introduced threat modeling as a critical ingredient for development of secure