idexcel

Application Security Testing

White Paper

An Integrated Approach

IntroductionApplication security is the use of hardware, software and procedural methods in order to protect applications from inter-nal or external threats. As more and more applications are becoming accessible over networks, they are being exposed to a wide variety of threats as well. Even the most sophisticated application security systems are prone to breaches, and demand stringent automated and manual test strategies at each stage of the software development life cycle (SDLC). In this paper, we will gain basic understanding of the different kinds of the application security vulnerabilities, and methodi-cal planning to mitigate the associated risks.

Markets are being flooded with applications each day in several domains. As these applications are getting increasingly complex and visually appealing, they are also becoming the main source of data and security breaches.

A recent survey of security breaches at Fortune 500 companies showed that breaches in information security could result in annual financial losses of up to $24 billion. With that said, 90% of large corporations have found one or more breaches in their computer security and even worse, 70% of those detected breaches were considered severe, many resulting in proprietary information theft and financial fraud. The hackers can use several different paths through any application to harm the business. If companies secure host and network-level entry points, focus of attacks usually shifts to the public interfaces.

One of the biggest challenges faced by architects, programmers, security consultants and testers is to analyze the vulnera-bilities of the application once deployed into production. As there are lots of dependencies, it is difficult to understand everything that will happen during application execution. It is quite difficult to say that any application is absolutely safe without doing aggressive testing, at the right time, with the right tools and information.

To combat these challenges, application firewall is one of the most basic software countermeasures as it limits the handling of data by specified installed programs or execution of files. Router is a common form of hardware countermea-sure and it prevents the IP address of any specific computer from becoming directly visible on the internet. Conventional firewalls, anti-virus programs, encryption/decryption programs, biometric authentication systems and spyware detection and removal programs are other countermeasures. However, when the security measures are built into the application, there are lesser chances that the unauthorized code will get access, modify, steal or delete the sensitive information. For this built-in security approach, we first need to have an in-depth understanding of the vulnerabilities of the application, and analyze how these vulnerabilities affect the application and system performance.

idexcel

2 P a g e

An Integrated Approach

Attack

AttackVectors

ThreatAgents

SecurityWeaknesses

SecurityControls

TechnicalImpacts

BusinessImpacts

Attack

Attack

Weakness Control

Control

Control

Asset

Asset

Function

Impact

Impact

Impact

Weakness

Weakness

Weakness

Each path represents a risk, which may or may not be serious.

Courtesy- OWASP

Application Security VulnerabilitiesVulnerability is a weakness in the system which can be exploited by the malicious users. Increase in bugs in the software, viruses and lack of security testing can increase the vulnerability of any application. In recent years, attacking application vulnerabilities has been the top priority of several criminal organizations. Several vulnerabilities are discovered on a regular basis, and even the government sites have been often compro-mised by the attackers to infect thousands of browsers that access those websites. Any app development orga-nization that fails to sanitize user input by filtering out unneeded but potentially malicious character sequenc-es, does not check the size of user input or does not initialize and clear variables properly, can become vulnerable to remote compromise.

Errors in applications occur due to insufficient practices or processes, incomplete supporting technology or inadequate skill. The most common issues are the failure to define detailed and clear security require-ments, failure to perform security testing and lack of threat modelling activities. Developers are usually not trained in the secured coding, and only a few organiza-tions have application security and security testing teams to support development projects. Attacker can inject certain exploits such as SQL injection attacks, buffer overflows, cross-site request forgery, cross-site scripting, or click-jacking of the code in order to gain control over the vulnerable machines.

Let us take a closer look at these vulnerabilities, and their effect on the application security. As per OWASP, the top 10 application security vulnerabilities are as follows:

3 P a g e

implementation of application. Injection flaws such as LDAP, SQL and OS injections occur when ambigu-ous data is sent to the interpreter, as part of the query or command. The interpreter can be tricked by the hostile data of the attackers, and either can access data without relevant authorization or execute unin-tended commands. Cross Site Scripting, also known as CSS or XSS, and is a vulnerability mainly found in web applications that allow the attacker to inject JAVASCRIPT and HTML code into the web page and inject malicious scripts into the victim’s web browser. Hackers can steal vital information stored in cookies. The application sends untrusted data to the web browser without proper validation. By executing the scripts in the victim’s browser, attackers can hijack user sessions, redirect user to the malicious sites or deface web sites.

Broken Authentication and Session Management Application functions related to the management of session and authentication are usually not correctly implemented, and allow hackers to compromise keys, passwords, token, or to exploit other flaws.

Sensitive data exposure - If applications do not protect sensitive data such as authentication creden-tials, credit card numbers, bank details, or tax IDs, attackers may modify or steal the weakly protected data and commit identity theft, credit card fraud or other crimes. Passwords are sometimes stored in cookies, and if stored without encryption, hackers can get the username and password information.

Insecure Direct Object References - When the devel-oper exposes a reference to an internal implementa-tion object such as database key, directory or a file, it is called adirect object reference. As there is no check for access or any other protection, hackers can access unauthorized data by manipulating these references.

An Integrated Approachidexcel

Injection is a common application layer attack tech-nique used by hackers to steal data from companies. Hacker can get vital information from the server data-base by taking advantage of the loop holes in the

4 P a g e

An Integrated Approachidexcel

Missing function level access control - Before any functionality is made visible in the user interface, the function level access rights verification is done. How-ever, same access control checks need to be performed on the server when each function is accessed. The request needs to be verified, else, hackers can forge a request to access functionality without proper authorization.

Using components with unknown vulnerabilities Frameworks, libraries and other software modules usually run with full privileges. Hackers can exploit any vulnerable component and attack can cause server takeover or serious data loss and theft. Cross-Site Request Forgery (CSRF) - In this attack, the victim’s browser is forced to send the forged HTTP request, along with session cookie and other auto-matically included authentication information. Attacker forces the browser of the victim to generate

requests, and vulnerable application thinks that these requests are legitimate. Un-validated redirects and forwards - Users are often redirected to other websites and pages by Web applications, and use untrusted data to determine the target page. If proper validation is not done, attacker may redirect the victims to any malware or phishing sites. Security misconfiguration - Good security has secured configuration for application, application server, frameworks, database server, web server and platform. Secure settings must be defined, imple-mented and maintained, and Software must be kept up to date. To deal with these vulnerabilities, and assess systems or software for the presence of securi-ty weaknesses, application security testing must be done by specialized testers using specialized tools.

Web Hacking Incident Database (WHID)

Based on ~1300 hacking or data breach reports published in the news since 2000, updated manually. Some reportscover multiple compromised servers (up to 90’000 at once), but each such campaign

Attack methodTop 10 methods of websites compromise

Denial of Service

Cross Site Request Forgery (CSRF)

Credential/Session Prediction

Banking Trojan

Unintentional Information Disclosure

Stolen Credentials

Predictable Resource locationBrute Force

Cross Site Scripting (XSS)

Source: Web Hacking Incidents Database (WHID), Feb 2013, n-895

Full data (CSV): WHID attack methods count, WHID attack methods percents.

WebAppSec_org

Table at Google: Web- Hacking- Incident-Database. Project page :

SOL Injection

Denial of Service

SQL Injection

Cross Site Scripting (XSS)

Brute Force

Predictable Resource Location

Stolen Credentials

Unintentional Information

Disclosure

Credential/Session Prediction

Cross Site Request Forgery

Banking Trojan

(CSRF)

Percetage

25%

24%

8.9%

4.8%

3.8%

2.8%

2.1%

1.9%

3.7%

3%

5 P a g e

An Integrated Approachidexcel

Application Security Testing Tools

67% - Lack of Availability of right testing

tools

53% - having to maintain multiple

versions ofhardware,

middleware andsystems under test

37% - Inability toestablish testenvironments

in a timelymanner

45% - Lack of clarity on

e�cient usageof available

con�guration

44% - Lack of availability

of right hardware

36% - Lack of availability of

right operating

system

The World Quality Report 2013-14 indicates several testing challenges faced by organizations:

In order to address these challenges and mitigate the risks posed due to vulnerabilities listed in the previous section, organizations need to design a comprehensive application security testing plan that can provide com-pliance and security. To design this plan, organizations need to answer the following:

Do we have a firm grasp on the most significant vulnerabilities and risks, and are we addressing these issues frequently?

If our applications are attacked, can we detect them, prevent them, and deal with them? How do we know that our existing application securi-ty infrastructure is effective, and delivering return on investment?

Are employees following the organization’s security procedures and policies, and are these enough to mitigate the risks involved?

Vulnerability Assessment - Process that identifies and classifies security holes or vulnerabilities in the application, and can help forecast the effectiveness of the proposed countermeasures, and evaluate the effectiveness of these measures once they are put into use. Vulnerability scanning can be done with the help of vulnerability scanner which is a program that performs the diagnostic phase of the vulnerability assessment.

Once these questions have been analyzed and answered, the following tools can be used to put the plan to practice. Some of the commonly used application security testing tools are:

6 P a g e

An Integrated Approachidexcel

Threat Modelling - Application security can be improved by using a process called Threat Modelling. It is an application risk assessment tool that helps system designers to understand security threats that their application might face. It helps designers to develop mitigation strategies for the vulnerabilities, and focus their attention where it is required most. Threat model should be created as early as possible in the SDLC. This process involves defining enterprise assets, identifying the functionality of each asset with respect to these assets, outlining security profile for each application, understanding and prior-itizing threats, and documenting the actions requires for each case. Threat can be any actual or potential adverse event that is capable of compromising the asset. The event can be malicious such as denial of service (DoS) attack, or any unplanned event.

Code Analysis - Integrating security measures into the Software Development Life Cycle (SDLC) is crucial to application security. One of the measures is the static and dynamic source code analysis to test for technical and logical vulnerabilities, and to know if the application can withstand malicious attacks. Static analysis is reviewing the application source code without executing the application, and analyze what the code does during each program execution. However, some issues become apparent only during system integration, component-level integration or deployment. Hence, dynamic analysis needs to be conducted once static analysis is done. It reveals behaviour of the application when executed, and its interaction with operating system and other process-es. Static analysis finds errors early in the SDLC, and dynamic analysis tests the code in a real-life attack scenario.

Penetration Testing - Penetration Testing is a process to identify security vulnerabilities in the application by evaluating the network or system with various malicious techniques. This testing helps protect the identified vulnerabilities, and secure data from malicious users. There is white box and black box penetration testing. In black box testing, the tester does not have any information about the system under test, whereas in whitebox penetration testing, the tester has all the information such as IP address, code, and infrastructure diagrams prior to starting the tests. Runtime Analysis - Runtime analysis tool closely monitors the behaviour of the application for debug-ging and validation. It uses source code insertion to instrument the source code, and provides dynamic analysis of the running application on native or embedded target platform. Code coverage performs code coverage analysis, performance profiling provides performance load monitoring, memory profiling provides performance load monitoring and runtime tracing draws the real-time UML sequence diagram of the application. Runtime analysis involves assessing the application for security issues from the end users’ perspective. For this analysis, the tester does not have access to source code, and has the same kind of knowledge as an external attacker. Runtime analysis helps quickly detect memory corruptions and critical security vulnerabilities. Binary Analysis - Applications these days are usually a mash-up of code from several sources. Binary code analysis scans compiled or byte code so that the orga-nization can test more accurately and comprehen-sively. As computers execute binaries, not source code, binary analysis provides ground truth about application behaviour.

7 P a g e

An Integrated Approachidexcel

Authentication - Test for user enumeration, authenti-cation bypass, brute force protection, autocomplete on password inputs or forms, logout functionality presence, cache management, default logins, user-accessible authentication history, out-of-chan-nel notification of account lockouts and successful password changes, and consistent authentication across applications with shared authentication schema. Also test password quality rules, remember me functionality, password reset and recovery, pass-word change process, CAPTCHA, and multi factor authentication.

Authorization - Test for path traversal, missing autho-rization, bypassing authorization schema, vertical access control problems and horizontal access control problems.

Denial of Service - Test for anti-automation, account lockout, SQL wildcard DoS, and HTTP protocol DoS.

Business Logic - Test for feature misuse, lack of non-repudiation, integrity of data, trust relationships and segregation of duties. Risky functionality (File Uploads) - Test that accept-able file types are whitelisted, file contents match the defined file type, file uploads have anti-virus scanning in place, unsafe filenames are sanitised, uploaded files are not directly accessible within the web root, and uploaded files are not served on the same hostname or port. Also test that the file size limits, upload frequency and total file counts are defined and are enforced. Files and other media must be integrated with the authorisation and authentication schemas. Risk Functionality - Card Payment - Test for known vulnerabilities and configuration issues on the appli-cation and server. Also test for guessable or default

passwords, injection vulnerabilities, non-production data in live environment, insecure cryptographic storage, buffer overflows, improper error handling, insufficient transport layer protection, Cross-Site Request Forgery (CSRF) and authentication and authorization.

Data Validation - Test for reflected cross site script-ing, stored cross site scripting, cross site flashing and DOM based cross site scripting. Also test for SQL, HTML, ORM, LDAP, XXE, XML, XPath, SSI, Code, XQuery, command, expression language, and IMAP/SMTP injection. Test for format string, incubat-ed vulnerabilities, HTTP Verb Tampering, HTTP Smug-gling or Splitting, Open redirection, remote file inclu-sion, local file inclusion, Null/invalid session cookie, mass assignment, auto-binding, HTTP parameter pollution and NoSQL injection. Also compare client-side and server-side validation rules. Obfuscation - Is used to make the program much harder to understand and protect it from attacks. Information Gathering - Explore the application, crawl/spider for the hidden or missed content, check for caches, check for files that expose content, perform fingerprinting, and identify user roles, tech-nologies used, client-side code, application entry points, multiple versions or channels, all host names and ports, third-party hosted content and co-hosted and related applications.

Configuration Management - Check for commonly used application and administrative URLs, old and unreferenced files, Cross Site Tracing and HTTP meth-ods supported. Test file extension handling. Test for policies, non-production data in live environment and security HTTP headers. Also check for sensitive data in client-side code.

An Integrated Approach

8 P a g e

idexcel

Secure Transmission - Check SSL version, key length, algorithms, session tokens and credentials. Check for digital certificate validity and if HTTP Strict Transport Security is used.

Session Management - Check session tokens for cookie flags, session cookie scope, and duration, session termination after maximum lifetime and termination after relative timeout, session termina-tion after logout, and establish how session manage-ment is handled in the application. Test for consistent session management across applications with shared session management, session puzzling and CSRF and clickjacking. Test session cookies for randomness, and confirm that new session tokens are issued on login, logout and role change. Test to see if users can have multiple simultaneous sessions.

Cryptography - Check for weak or wrong algorithm usage, randomness functions, proper use of salting, and check if data which should be encrypted, is not. Additionally, establishing audit trail for data, and ensuring that the back end is secure, and validating all potential client-side routes into the application, are also some of the important measures to ensure application security. In order to cover all these aspects of application security testing and to have a comprehensive test plan and implementation in place, an organization can follow the steps below:

1. The process of preparing and planning for the application security testing begins with an under-standing the business requirements, the objectives of security compliance of the organization and secu-rity goals. The test planning must consider all these security aspects.

2. Analyze and understand the requirements of the application which is being tested.

3. Collect all the setup information used for the development of software and network including technology, operating system, hardware etc.

4. List out all the application vulnerabilities and secu-rity risks, and based on this list, prepare a threat profile and a test plan to address the issues.

5. Prepare a traceability matrix for each identified vulnerability, thread and security risk for the applica-tion.

6. Security testing cannot be done manually, and hence, identify tools to execute the test cases faster, in a more reliable manner.

7. Prepare security test cases, execute test cases, and retest the fixes.

8. Execute regression testing.

9. Prepare a detailed Security Testing report contain-ing threats and vulnerabilities, detailed risks, and open issues.

10. Internally developed and third-party applications must be thoroughly tested to find security flaws. In case of third party software, the company should ensure that the vendors have conducted comprehen-sive security testing of all the aspects of the applica-tion. For in-house developed applications, compa-nies need to conduct these tests or engage an outside firm that specializes in application testing.

9 P a g e

An Integrated Approach

Integrated Approach

In order to make these tools and testing more effective and useful, it is a good practice to include security in each phase of the SDLC so that security bugs can be prevented, rather than fixed. This is the era of proactive testing, and fixing bugs in the deployment phase can be a very cost-prohibitive and an ineffective practice. Integrating testing in each phase of software develop-ment can ensure that the security has been adequately covered, and controls are effective throughout the development process. Integrated security testing systems covering the widest possible range of assets represent the promise of a future where companies are not left wondering where the most threatening risks lie. Only integrated, multi-tiered security testing across networks,

idexcel

endpoints, applications and end users can provide a centralized and comprehensive approach to risk manage-ment. Independent, comprehensive application testing software solutions offer the most effective way to expose critical application vulnerabilities, mitigating the risk and ensuing timely action.

There are also dynamic application security testing (DAST) solutions available capable of effectively testing modern applications using newer technologies such as AJAX, Rest, GWT and JSON. These services are available as SaaS and deliver comprehensive application coverage and sophisticated attack methodologies, and eliminate false positive and false negative findings.

• Deployment /Operational Security

• Patch Management

• Incident Management

• Threat Model Update

• Measurements

• Security Requirements Engineering

• Compliance Goals

• Industry / Organizational Standards

• Technical Requirements

• Threat Modeling Lessons

• Measurements

• Threat Modeling

• Architecture & Design Patterns

• Security Test Planning

• Architecture & Design Review

• Measurements

• Attack Patterns

• Automated Testing

• Regression Testing

• Stress Testing

• Third Party Assessment

• Threat Model Updates

• Measurements

• Code Review

• Security Patterns

• Flaw & Bug Mitigation

• Unit Testing

• Threat Model Updates

• Measurements

METRICS

TOOLS

TRAINING

POLICY

SECURITY AND THE SOFTWARE

DEVELOPMENT LIFECYCLE

Courtesy - FoundStone

Launch Secure Application

10 P a g e

idexcel

ConclusionTechniques and tools for testing are changing, becoming more sophisticated, and efficient with each passing year and organizations that do not take proactive application security testing measures are increasingly being seen as laggards as they fail to comply with the critical IT best practices. There is no actual right and wrong tool, and probably all techniques must be used to ensure that all the areas are exhaustively tested. A balanced approach includes several techniques involving manual reviews and technical testing to cover testing in all the phases of SDLC.

Test early and test often. Use the right tools. Before you buy, take a good look at all the free tools available, and if they don’t suffice, you can look for paid tools. Some tools also give a certificate if no vulnerabilities are found. Keep in mind that new security threats are emerging all the times, and it requires extra effort to stay updated, and be proactive in order to keep your apps and system secure.

Launch Secure Applicationidexcel

About the AuthorHarsha B N works as a Test Architect in the Mobility division of Idexcel. He has twelve years of experience in develop-ment and testing mobile applications. Prior to joining Idexcel Harsha worked with Nokia for eight years in various capacities as Program Manager, Chief Test Engineer, Project Manager working on OTA infrastructure development, Mobile Payments services, S60 SDK.

About IdexcelIdexcel is an innovative provider of IT Products & Services focused on emerging technologies. We help world leading companies build efficiencies and stronger businesses. With more than 15 years into existence Idexcel’s main focus is client satisfaction and technology innovation. Our industry expertise and a global, collaborative workforce forms the backbone of our services. We offer high degree of skills in Enterprise Applications, Cloud Services, Data-warehousing, Big Data, Analytic, QA & Testing Services, IT consulting and Staffing. Idexcel product line includes: NDS, ERP, and Cync - A revolutionary credit monitoring application for the manufacturing and �nancial management.For more information log on to www.idexcel.com.

Global Head quarters459 Herndon Parkway Suite 11Herndon, VA 20170Tel: 703-230-2600Fax: 703-467-0218Email: inquiry@idexcel.com

India Operations“Crystal Plaza” 9, 10 ,11Bhuvanappa Layout, Hosur RoadBengaluru – 560 029KarnatakaTel: +91-80-2550 8830Email: inquiry@idexcel.com

© Copyright, Idexcel. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Idexcel. The information contained herein is subject to change without notice. All other trademarks mentioned herein are the property of their respective owners.