Web Application Security

Download PDF
12 downloads 338223 Views 245KB Size Report
Comment
Most of these vulnerabilities are directly related with the web-based applications lack of quality as a result from a poorly implemented software development life ...
Web Application Security Improving Critical Web-based Applications Quality through in-depth Security Analysis

Nuno Teodoro

Carlos Serrão

ISCTE-IUL School of Technology and Architecture ISCTE-IUL Lisbon University Institute, ISTA, ADETTIIUL Ed. ISCTE, Av. Forças Armadas, 1649-026 Lisboa, Portugal [email protected]

ISCTE-IUL School of Technology and Architecture ISCTE-IUL Lisbon University Institute, ISTA, ADETTIIUL Ed. ISCTE, Av. Forças Armadas, 1649-026 Lisboa, Portugal [email protected]

Abstract— The Internet, and in particular the World Wide Web, have become one of the most common communication mediums in the World. Millions of users connect everyday to different web-based applications to search for information, exchange messages, interact with each other, conduct business, pay taxes, perform financial operations and many more. Some of these critical web-based services are targeted by several malicious users intending to exploit possible weaknesses and vulnerabilities, which could cause not only the disruption of the service, but also compromise the users and organizations information. Most of the times, these malicious users succeed in exploiting different types of vulnerabilities and the consequences can be disastrous. Most of these vulnerabilities are directly related with the web-based applications lack of quality as a result from a poorly implemented software development life cycle (SDLC). This paper will discuss the direct implication of the lack of security and the importance of quality on the SDLC, and the major factors that influence them. On the other hand the authors propose a set of security automated tools and methodologies that can be used throughout the SDLC as a mean to improve critical web-based applications security and quality. Keywords- Web Application, Security, Automated Testing, Quality, Critical

I.

INTRODUCTION

Security was, still is, and always will be one of the major concerns that critical systems have, especially when deployed in the World Wide Web, accessible through a web browser. Nowadays, there are a huge amount of services deployed in the World Wide Web and people rely on this communication system to perform everyday operations. Examples of these operations are: tax payments, banking operations, e-shopping, e-mail, government healthcare system operations and so forth. Moreover, in some countries, these operations are actually mandatory, one example of this, is Portugal, where the public administration services were totally deployed in the Web [18] aiming at bringing together government and citizen. Most security concerns are now related with the application level. This has one simple explanation, web applications are accessible through browsers, and can be accessed by everyone with Internet. This has the inherent possibility that good or badly intentioned people can take advantage of this and

perform malicious actions. The number of attacks documented by some entities easily confirms this. The National Institute of Standards and Technology (NIST) holds a National Vulnerability Database (NVD), which has over 40000 vulnerabilities, identified in the application level as of March 13, 2010 [10]. This is also confirmed by the Gartner Group, which estimates that 70% of the attacks to a company’s web application come from the application level. The biggest difficulty with web applications security and quality is hard and invokes a set of skills, which may not always be available within the business and development team. One of the reasons of this difficulty relates with the number of variables they relate with. Their security relates with network, Internet, transport and application layers and the biggest challenge is to have relatively good security implementations at every one of the layers and be extremely good at the most critical one. Most times this does not happen and network security is privileged in detriment of others. The rationale behind this paper is precisely to prioritize methodologies and tools, which can perform application level security assessment improving software quality. These tools must be present in every stage of the software development life cycle (SDLC) [21], mitigating possible errors, which can occur in each cycle. Before delving into a security blind deployment, these tools and methodologies should be used to perform basic, but important, security verifications, assuring quality standards, which may be required, and preventing malicious attacks. II.

WEB APPLICATIONS AS THE WEAKEST LINK

Web applications no longer relates with back offices and home entertainment. These days, web applications have become the most important applications in everyone’s life and relates with most operations users make in the Internet. Security professionals often misunderstand the true issues related with security flaws nowadays - software. Software is the weakest link in security. Application level security relates with many issues within this topic and it cannot be minimized to good programming practices. Proof that security issues relate with software is that, besides the number of application level vulnerabilities exploited over the last few years is

growing, organizations like OWASP [13], WASC [5], CERT PT and so forth are becoming each day more active and security professionals are starting to understand and assume precisely their recommendations. OWASP Top 10 [12] and the WASC threat Classification [5] point precisely to the most common application layer security problems, which derive from a vast experience from security professionals around the world. One of the biggest problems relate with reactivity instead of proactivity. Reactivity means that the problem has already happened and consequences had already taken place inside the organization. Obviously this is not the right path. Proactivity should be the way. Proactivity should be present in web applications quality. Quality should be proactive and as a result, security issues will be discovered in a prior stage, inside the organization, and not from outside, from external attackers. III.

WEB APPLICATIONS QUALITY

Software quality should be exceptionally well defined to the development team and project manager and should also be a common word though the organizations hierarchy thus defining important and measurable indicators with which it is possible to assess the overall development quality. Quality can have a huge amount of definitions according to the clients needs. This is commonly accepted and developers usually think in quality as functional requirements. Quality should, first of all, consider software bugs. All web-based critical operations must have security as a quality measurement, precisely because security issues derive from development bugs and unexpected software behavior. Quality should be the number one concern with these applications. As a result of this need of quality, we will define it as the integration of security in the Software Development Life Cycle (SDLC). Critical web applications quality should assure confidentiality and integrity of the users of those applications while data is transmitted, handled and stored. It should also address issues as confirming that the web application cannot be compromised at any level by hackers. This also implies that risks should be defined, establishing acceptable levels of risks and defining threat models, preparing developers and quality engineers for the expected behavior and improvements. One important tool to assess critical web applications quality is the OWASP Top 10. This is a valuable document, which defines the 10 most common problems web applications suffer which facilitate attacks through them and therefore should be taken into account into the development process. Why is quality so important after all? Why cannot critical web applications be developed using the usual methods, which will allow them an earlier market entrance, solving the problems in a later release? The answer is simple, besides the common sense which alerts to the dangers that users of those applications can be targeted, it is also important to understand that, after those web applications are compromised, the organizations name can be irreparable damaged and all assets lost [2], adding, to the costs of the losses caused by the attackers, the possibility of a total market loss, resulting in the organizations death. Additionally, although opinions in this matter divide, several studies show that solving these problems

after deployment can be orders of magnitude more expensive than integrating security with the SDLC, specially when dealing with web applications which are created for organizations which have the entire operations based on them. IV.

SECURITY INTEGRATION WITH THE SDLC

The complexity and market demand in critical web based applications has made an increase in the growth of security models in the software development life cycle [20]. One of the bases for these methodologies is that security must be present through every phases of the SDLC thus achieving quality as a final product. This often involves communications and interaction from top chairs (CIO, CEO, and others), running down the hierarchy, through project managers and developers. The point of this organizational awareness is simple, security is a process, not a final product, and should be dealt as such, integrating experiences, visions and concerns from everyone. Next in this paper it will be briefly described MS DLC and BSIMM. OWASPs SAMM will be further analyzed as it is the integrated within OWASPs work, and organization that is worldwide renowned in the web application security field. A. Microsoft Security Development Lifecycle (MS DLC) Microsoft’s methodology is maybe one of the most used in the commercial area. This is mostly driven by the fact that their products are present through every markets and technologies, enforcing the use of their patterns. MS DLC [9] is described by Microsoft as being versatile (applies to large, medium and small companies, to various development methodologies and to any platform), cost-effective (they present a study by NIST which claims that code fixes after the deployment can go up to 30 time than if perform in the development phase) and measurable (they present studies comparing the number of vulnerabilities with and without their platform). B. Building Security in Maturity Model (BSIMM) BSIMM [3] was born from a study of analyzing nine software leading development companies, where Microsoft, Google and Adobe take part in. This is obviously an incredible point of trust in this model as it has its bases in global distribution software companies. Due the scope of this paper, Microsoft and Google give this security framework a special credibility due to their web-based applications. BSIMM defines a Software Security Framework (SSF), which is defined by: Governance, Intelligence, SSDL Touch Points and Deployment. These four stages all have security activities associated. Governance security activities are composed by: strategy and metrics, compliance and policy and training. Intelligence stage security activities are: attack models, security features and design and standards and requirements. SSDL security activities are: architecture analysis, code review and security testing. Finally, the Deployment stage is composed by the following security activities: penetration testing, software environment and configuration management and vulnerability management. BSIMM aims at developing a maturity model, which would imply to change the way organizations work. It is understood that this does not happen quickly and therefore this framework

provides a way to assess the state of organizations, define which changes should be prioritized and demonstrate progress. C. OWASP Software Assurance Maturity Model (SAMM) The OWASP SAMM [14] is a framework, which aims helping organizations to formulate a security strategy for software security. This framework provides all the resources for free and aids in: •

Evaluating the current practices in the organization related with software security

•

Building a balanced software security assurance program for specific iterations

•

Demonstrating improvements to a security assurance program

•

simpler ones also exist and are easier to implement for small projects or companies. In many cases, a SDLC as shown in Fig. 1 is enough for most projects.

Security Requirements

Requirements and use-cases Design Review Risk Analysis

Design Risk-based security tests

Test Planing

Defining and measuring security-related activities throughout an organization.

Code review

As the previous models this framework was developed with flexibility in mind. It is understood by this framework developers that not all organizations are equal and can apply security frameworks without some level of adaptability. SAMM framework structure has two main layers, one layer where Business Functions (BF) are defined and another one with Security Practices (SP). The BF layer includes Governance, Construction, Verification and Deployment. These four phases define the SDLC for OWASP in this framework, each one of them fully described in their documentation. The SP, which is integrated with each one of the BF processes previously defined, is executed in such order that assures that security is present in every life cycle and is gradually integrated with the functional phase, assuring software quality at any stage. This is important as it defines specific security processes, which will meet the life cycle security expectations while delivering to the next cycle, the desired quality. Security practices for Governance are: strategy and metrics, policy and compliance and education and guidance. In the construction BF, security practices are: threat assessment, security requirements and secure architecture. In one of the most quality related phases, verification, security practices are defined by: design review, code review and security testing. Finally, at the deployment stage, security practices include: vulnerability management, environment hardening and operation enablement. Frameworks such as the Microsoft Security Development Lifecycle (MS DLC), the Building Security In Maturity Model (BSIMM) and the OWASP Software Assurance Maturity Model (SAMM) are some of the most known methodologies for integrating security within the SDLC. These methodologies are most often criticized due to their time and resources consumption but it is important to understand that, as most methodologies, they are to be used when necessary and adapted to the organizations reality. This paper focuses on critical web applications, and these, are one of the most important applications, which should be developed under these methodologies. Besides these well known methodologies,

Coding Static analysis (tools)

Test Results and Field Feedback Penetration testing

Figure 1. Security in the SDLC, a simple approach

V.

ENSURING QUALITY THROUGH SECURITY ANALYSIS

Implementing security in the SDLC must be a smooth process. Trying to start with a security framework, as the ones previously mentioned can be a bad call. If the entire organizational structure is oriented in such a way that no security concerns were taken in the past for developing web applications, changing the entire process can be too time consuming and can actually conduct to a worst application development. We define a number of steps to these organizations, which should be adapted and taken into account in organizations, which want to delve into these frameworks. These steps will help the organization to achieve a high quality rate in critical web applications by integrating deep security analysis at every stage of the SDLC. A. Training and Awareness Increasing First of all, security must be present in the organizations culture. Security must be a state of mind. When an organization does not care with security, people will not be security driven. Developers will not care about developing in a secure kind of way, managers will not care about security requirements, and the organization top management will not care about creating new and better ways of increasing their personnel competences in this domain.

Stakeholders must understand web applications security problems but not become security experts overnight. They must, instead, become aware of which security problems web applications suffer, and how to solve them. Sometimes it is also recommended that security consultants are hired as part of the team so that specific questions or problems can be quickly solved. B. Web Applications Prioritization When starting these processes, it is wise to define which new web application development should be targeted. This is important because new processes not always are well understood, and important developments can be compromised. Web applications nowadays are complex systems, which integrate a number of technologies that, in a security point of view, can be, by them, the point of failure of an entire system. This is important to web application prioritization because integrating new activities in a well-defined SDLC in a very complex system can escalate the previously described problem. C. Risks Classification Web applications development is a risky activity [8][19] due to the fact that they face many risks. Risk categorization is one of the most important phases because this can define if actual defining a security model in the SDLC is going to be useful. IF a security model is integrated in the SDLC but the security flaws are not properly corrected, its not going to be very useful. For this stage, the most important risks should obviously be mitigated first. When dealing with critical web applications, application level security is the key point. OWASP Top 10 2010 is perhaps the most valuable document developers can rely on. This document describes the most common vulnerabilities web applications suffer, in a carefully ordered way. The OWASP Top 10 for 2010 is, in a succinct way, the following:

D. Security Requirements Definition Functional requirements are defined before development in every SDLC. On the other hand, security requirements are never defined. While dealing with critical web applications, quality must be defined as the union of functional and security requirements. Defining security requirements can be hard and must be done properly or else, they will be pointless. Security requirements must start with a generic set as the following: •

Include all security mechanisms

•

Address all common vulnerabilities

•

Use cases

•

Address all driving requirements standards, best practices, etc.)

•

Specify how authentication will work

•

Detail the access control matrix (roles, assets, functions, permissions)

•

Define the input validation rules

•

Choose an error handling and logging approach

(regulation,

At this stage it is also important to seek for an outside view. Users of the application may have important information about the quality standards and security requirements for the application they are going to use. Additionally, the organization should define Service Level Agreements (SLA), privacy and data protection policies and compliance standards. E. Threat Modeling Threat modeling is very important. When modeling possible threats, a more accurate perspective about security flaws, becomes evident. Threat modeling starts by being capable of defining the right threat. After that stage, it is important to have some tacit and technical knowledge to understand those threats and build several possible cases, which may have lead to the modeled threat in the first place.

1.

Injection

2.

Cross Site Scripting (XSS)

3.

Broken Authentication and Session Management

4.

Insecure Direct Object References

5.

Cross Site Request Forgery (CSRF)

6.

Security Misconfiguration

•

Accidental bugs discovery

7.

Failure to Restrict URL Access

•

8.

Unvalidated Redirects and Forwards

Automated Malware, which can harm the web application

9.

Insecure Cryptographic Storage

•

Curious Attackers, which will try to perform operations in the web application which were not supposed to be executed

•

Script Kiddies

•

Motivated Attacker - this must contemplate threats from inside the organization, which is one important source of web applications security flaws

Finally, solutions ate design to mitigate the discovered causes to the defined threats. This is not a perfect system and threats may continue hidden if they are not defined in this model. To diminish this problem, threats should be categorized. Some usual categories for web applications are:

10. Insufficient Transport Layer Protection Besides technical risks, business risks should also be categorized, for this matter, threat modeling is very important, as it defines which may be the main risks the web application suffers when integrated in a specific business.

•

Organized Crime, although not always thought of, critical web applications may be the target of organized groups which will try to damage specific services

The plus side in threat modeling is that, with the continuation of this process, people will become threat modeling experts for web applications and there will be an overlapping of the previously defined models to new applications development thus enhancing quality and security. At this stage it is important to study and follow OWASP Threat Risk Modeling [17] which is a valuable document as it defines Microsoft Threat Modeling Process as well as alternative threat modeling systems like Trike, AS/NZS 4360:2004 Risk Management, CVSS and OCTAVE. F. Architecture Design Reviews Architecture design is becoming one of the most important security features. Proof of this is Google Chrome and Qube OS, which rely on an architecture design that confers them a high rate of security. Google Chrome has been considered the most secure browser for 2010 in the Pwn2Own contest. This can be a hard, but important feature in web applications security. Web applications architecture is perhaps the most widespread concept within developers. The goal here is to ensure that specific parts of the web application cannot directly access sensitive areas. This often relates with database information and objects being accessed and manipulated when they should not. G. Secure Coding Secure coding is hard. Everyone can write software. Secure software it’s a different story. This problem arises right from the developer’s academic formation. Most of them have never heard anything about security or how to program with security in mind. The first step is to establish three important stages: • •

•

Secure coding training, which is obviously to be done before the coding process as started. Source code review, which can be done both statically (by a security focused static analysis tool, peers reviews or by formal security code reviews) of with the use of automated tools Developer’s certifications. Developers should be certified in producing secure code for critical web applications. This will assure that quality and security are taken into account and executed by credentialed developers

At this stage, the OWASP Top 10 should be taken into account when coding the web applications as well as the huge amount of code review tools OWASP makes available to the developers. Another important resource in code verification is the OWASP Code Review Project [15], which, not only provides documentations on reviewing code, but also a tool, which is freely available for download.

H. Post-deployment Security Assessment Post deployment security reviews are perhaps the most common security assessments made for every web application. The difference here is that, when integrated in a security model with the SDLC to achieve a better quality product, these security analysis will be made in a controlled and internal environment, instead of being perform by an outside attacker. At this stage one most important security assessment methodology is Penetration Testing (PT) [6]. Penetration testing can be done both manually and automatically. Manual PT requires an extensive technical knowledge of problems with web applications and ways to explore and exploit vulnerabilities. This can be difficult to do in an organization with a low level of expertise in this matter. By the other hand, manual PT allows the execution of black-box and white-box testing due to the fact that the testers are the same who developed the web application, therefore having a full knowledge of the internal working. Automatic PT can be achieved using web scanners [7]. Web scanners are automated tools, which perform PT to a specific web application. They discover flaws by performing well-known attacks, and most of these tools are already capable of producing reasonable reports with a low level of false positives and negatives, and provide useful solutions to mitigate the problems found. Although the choice of a web scanner is not an easy task, and monetary issues may arise, open source web scanners are freely available and for this matter, a small set of them can be used to assess the final quality and security of the developed web application. Some open source web scanners are: •

W3af

•

Netsparker

•

Nikto

On the other hand, if a commercial web scanner is preferred, the following can also be used: •

Acunetix

•

N-stalker

•

WebInspect

The web scanners presented here are not the only ones in the market, and the right one should be chosen, according to specific criteria. Also, security live Linux CDs distributions like the OWASP Live CD Project [16] and Backtrack [1] present valuable resources at this stage. The OWASP Testing Guide [11] is also an important document for his final stage. This document helps testers to concentrate on the most common flaws web applications have and offers explanations and possible mitigations for each one of them, as well as the tools which can be used to explore confirm their presence.

VI.

CONCLUSIONS

Critical web applications quality cannot be separated from security problems. Security must be present in every critical web application as it is a quality measure every user take as granted. In this paper we focused in the integration of security practices in the SDLC. The SDLC aims at defining patterns and standards for producing software with a higher quality level. The integration of security within those models is vital for these applications, and therefore, security activities were defined according to each stage of the SDLC, leading to an increase of web applications quality through the entire development process. Some well-defined frameworks, which integrate security with the SDLC, were explained in this paper. These frameworks were based in the Microsoft Security Lifecycle, the Building Security Maturity Model and in the OWASP Software Assurance Maturity Model. Also a generic framework was defined, which contains simpler processes but still very effective. The reason to do this is that not always organizations have the capability of integrating such frameworks overnight, if they present a high level of change.

[3] [4] [5]

[6]

[7]

[8]

[9] [10] [11] [12] [13]

Finally, a number of well-defined steps are defined, explained how and why some stages are an essential part of security in the SDLC, as well as a set of documents and tools, which should be used at each stage. Standards on how to define a threat model, how to review code and tools to assist it are very important, and OWASP plays here an important role in aiding with this resources. Also a small list of commercial and open source web scanners was described, which should be taken into account when at the penetration testing phase.

[14]

Web applications are nowadays the gateway between people and everyday operations with the entire world. This must be understood, and therefore, quality standards must be raised, which from our point of view, it can only happen with the increase of security.

[18]

[15]

[16]

[17]

[19]

[20]

REFERENCES [1] [2]

Backtrack (2011). Backtrack linux - penetration testing distribution website. http://www.backtrack-linux.org/. (Access date: 15 June 2011) Brunil D. Romero M., H. M. H. and A., J. E. M. (2009). A methodological tool for asset identification in web applications. In IEEE Fourth International Conference on Software Engineering Advances, pages 413–418. IEEE.

[21]

BSIMM (2011). The building security in maturity model. http://bsimm.com/. (Access date: 15 June 2011) CERT.PT (2010). Cert.pt web site. http://www.cert.pt/. Consortium, W. A. S. (2010a). (Access date: 15 June 2011) WASC Threat Classification version 2.0. WASC. Consortium, W. A. S. (2010b). Web application security consortium web site. http://www.webappsec.org/. (Access date: 15 June 2011) Duan, B., Zhang, Y., and Gu, D. (2008). An easy-to-deploy penetration testing platform. In Young Computer Scientists, 2008. ICYCS 2008. The 9th International Conference for, pages 2314 –2318. Fong, E. and Okun, V. (2007). Web application scanners: Definitions and functions. In System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on, page 280b. Madan, S. and Madan, S. (2010). Security standards perspective to fortify web database applications from code injection attack. In IEEE International Conference on Intelligent Systems, Modelling and Simulation. IEEE. Microsoft (2011). Microsoft security development lifecycle web site. http://www.microsoft.com/security/sdl/. (Access date: 15 June 2011) NIST (2010). Nist cve and cce vulnerability database. http://www.simplex.pt/index.asp. (Access date: 15 June 2011) OWASP (2008). OWASP Testing Guide - version 3.0. OWASP. OWASP (2010a). OWASP Top 10 - 2010, The Ten Most Critical Web Application Security Risks. OWASP. OWASP (2010b). Owasp web site. http://www.owasp.org/. (Access date: 15 June 2011) OWASP (2010c). Software Assurance Maturity Model - A guide to building security into software development - version 1.0. OWASP. OWASP (2011a). Owasp code review project. http://www.owasp.org/index.php/Category: OWASPCodeReviewPro ject. (Access date: 15 June 2011) OWASP (2011b). Owasp live cd project. http://www.owasp.org/index.php/Category: OWASPLiveCDProject. (Access date: 15 June 2011) OWASP (2011c). Owasp threat risk modeling. http://www.owasp.org/index.php/ ThreatRiskModeling. (Access date: 15 June 2011) Simplex (2010). Simplex web-site. http://www.simplex.pt/index.asp. (Access date: 15 June 2011) Striletchi, C. and Vaida, M.-F. (2003). Enhancing the security of web applications. In Information Technology Interfaces, 2003. ITI 2003. Proceedings of the 25th International Conference on, pages 463 – 468. Trifonov, G. (2009). Reducing the number of security vulnerabilities in web applications by improving software quality. In IEEE 5th International Symposium on Applied Computational Intelligence and Informatics, pages 51–54. IEEE. Wikipedia (2010). Wikipedia page on systems de- velopment life cycle. http://en.wikipedia.org/wiki/ SystemsDevelopmentLifeCycle. (Access date: 15 June 2011)