In 2009, Heartland Payment Systems, Inc.

, A leading provider of debit, prepaid, and credit card processing company who processes more than 11 million transactions a day and more than $120 billion transactions a year acknowledge that it had been the target of a data breach -- in hindsight, possibly the largest to date with 134 million credit and debit cards exposed to fraud. A group of Hacker used most commonly used SQL injection to install spyware on Heartland's data systems and stole the credit card data. It can be avoided if proper and complete security testing has been performed on the application. It is clear that attacks targeting web applications are on the rise, as stories like these are all too commonplace. Not only are application attacks growing more prevalent, they are also costly. The research firm Gartner estimates that within the next year, 80 percent of all companies will have suffered through an application security incident. These web application flaws also place organizations at significant risk for noncompliance with government and industry regulations such as Federal Information Security Management Act (FISMA), Health Insurance Portability and Accountability Act (HIPAA), Sarbanes- Oxley (SOX), the Gramm-Leach-Bliley Act (GLBA), and the more recent Payment Card Industry Data Security Standard (PCI DSS). For attackers, web applications are both easy and worthy targets. Common flaws such as SQL injection, cross-site scripting, poor input validation and broken authentication conditions make it possible for attackers to easily infiltrate these applications to disrupt application availability and destroy or steal sensitive and private information like Social Security numbers and credit card numbers. Also, vulnerable web applications not only allow these miscreants to steal and manipulate information within that application, but also to use it as an entry point to the corporate network and back-end applications. Security Testing is one of the most underrated testing techniques which most of the software development company chose to ignore or even if they use it, they do it to sell their products. Most of the Applications designed today are web based applications or mobile applications. Their availability on internet makes them vulnerable to security attacks. Although most of the companies (except BFSI, Defence s/w developer) designing web based applications do claim that there product does not need security testing but In current scenarios, Security testing is need of almost every web based applications. Based on the nature of business of web based applications, security testing requirement can be low and maximum but a certain level of security testing is required on every application. Security Testing is vast fields which cover lot of areas like Network Security Testing ( firewall, port scanning etc), Application security Testing, Mobile Application Security testing, Cloud Security testing etc. but in this article we will only focus on Web Application security Testing. In order to understand the security Testing, we will have to first understand what security is : What is Security? Security is set of measures to protect an application against unforeseen actions that cause it to stop functioning or being exploited. Unforeseen actions can be either intentional or unintentional. What is Security testing? Security Testing ensures that system and applications in an organization are free from any loopholes that may cause a big loss. Security testing of any system is about finding all possible loopholes and

weaknesses of the system which might result into loss of information at the hands of the employees or outsiders of the Organization. The goal of security testing is to identify the threats in the system and measure its potential vulnerabilities. Security testing of any applications or software should cover the six basic security concepts: 1. Confidentiality: A security measure which protects against the disclosure of information to parties other than the intended recipient. 2. Integrity: A measure intended to allow the receiver to determine that the information which it is providing is correct. 3. Authentication: The process of establishing the identity of the user. Authentication can take many forms including but not limited to: passwords, biometrics, and radio frequency, identification, etc. 4. Authorization: The process of determining that a requester is allowed to receive a service or perform an operation. 5. Availability: Assuring information and communications services will be ready for use when expected. Information must be kept available to authorized persons when they need it. 6. Non-repudiation: A measure intended to prevent the later denial that an action happened, or a communication that took place etc. In communication terms this often involves the interchange of authentication information combined with some form of provable time stamp.

Integration of security processes with the SDLC: One of the most common questions is when to perform Security Testing? Most of the people believes that effective way to perform security testing is , when application is completely developed and deployed on production like environment (often referred as Staging or Pre-Prod environment) . But it is more effective when implemented on every phase of SDLC. It is always agreed, that cost will be more, if we postpone security testing after software implementation phase or after deployment. So, it is necessary to involve security testing in SDLC life cycle in the earlier phases. Lets look into the corresponding Security processes to be adopted for every phase in SDLC

SDLC Phases Requirements Design Coding and Unit Testing Integration Testing System Testing Implementation Support

Security Processes Security analysis for requirements and check abuse/misuse cases Security risk analysis for designing. Development of test plan including security tests Static and Dynamic Testing and Security white box testing Black Box Testing Black Box Testing and Vulnerability scanning Penetration Testing, Vulnerability Scanning Impact analysis of Patches

Application security Application Security is usually the use of software, hardware, and procedural methods to protect applications from external threats.
Application Security Testing Objective

The major objectives of the Application Security Testing are to: 1. Identify and understand the existing vulnerabilities. 2. Provide recommendations and corrective actions for improvement. 3. Examine and analyze the safeguards of the system and the operational environment. How to Approach for Application Security Testing There are many ways to perform Application security testing but best approach is Web Application Security Testing (WAPT). WAPT is a legally authorized, non-functional assessment, carried out to identify loopholes or weaknesses, otherwise known as vulnerabilities. These vulnerabilities, exploited by a malicious user (attacker/hacker), may affect the confidentiality, integrity, availability of the web application and/or information distributed by it. Some of the loopholes or vulnerabilities plaguing web

applications are SQL Injection (Structured Query Language Injection), XSS (Cross Site Scripting), CSRF (Cross Site Request Forgery), Remote File Include, etc. Apart from these, vulnerabilities may exist in the underlying infrastructure like Operation System, Web Server, Application Server, Database Server, etc. Thereby, WAPT aims at identifying and reporting the presence of these vulnerabilities. Benefits of WAPT Proactive protection of information assets against hacking and unauthorized intrusions Provides an insight into the current security posture of the given web application Provides a hackers eye view of the web application Aids in mitigating costs improving goodwill and brand value

WAPT Overview WAPT is carried out in a phased manner in order to ensure optimum coverage and at the same time simulate the fluid actions of a real time hacker. The following figure depicts the flow:

There are five phases to perform WAPT on the Application under testing.

Phase 1:- Information Gathering This is the most critical phase in the methodology as all further phases depend on this. As a part of this phase, information about the target web application collected. It includes detail of all software, Hardware, server, end users and information provided by the application. Phase 2:- Planning and Analysis All the data gathered in the above phase, is converted into usable information, in the form of a customized test plan. An important step in this phase is to prepare a checklist of tasks or areas (URLs) or applicable vulnerabilities to cover. 0 Phase 3:- Vulnerability Assessment This phase can also be dubbed as active information gathering phase. Various automated scans run against the target application and its underlying infrastructure (server(s) and network) to get the list of all such areas within application which can be exploited by hackers or vulnerable to malicious attacks. There are many vulnerability assessment tools like Nessus and SARA which can be used to perform vulnerability Assessment. Phase 4:- Attack/Penetration It is under this phase that the actions of a web application hacker are emulated. Based on the information gathered and analyzed in previous phases and following the customized test plan, attacks are carried out to identify the presence of vulnerabilities in the application. The techniques and tools used should be the same as those used by a real hacker. This is done in order to gain a hackers eye view of the application. There are many automated tools which can be used to perform Pen test. In most of the cases single tools does not fulfill the entire requirement so a combination of tool is required to get the maximum result. WebScarab, NMAP, BURP Suite, IBM App Scan, Acunetix Vulnerability Scanner, HP Web Inspect etc. are few tools which one can use to perform Pen test. Phase 5:- Reporting At the end of the Attack/Penetration phase, a comprehensive report prepared detailing each finding, assigning a suitable severity level to each, delineating the steps necessary to reproduce the vulnerability, and suggesting recommendations to address every vulnerability found during assessment. Top 10 list of web Application security The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. Most of the companies who do perform security testing follow OWASP model and top threat to validate their application. Based on the ongoing trend and attacks in web world they prepare top 10 list of web Application security threat in every 3 years. On June 6, 2013, OWASP foundation released the official updated Top 10 web vulnerabilities list for year 2013 onwards. These top ten threats should always consider when performing Security testing on any web application. 1. A1 Injection: Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attackers hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

2. A2 Broken Authentication and Session Management: Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users identities. 3. A3 Cross-Site Scripting (XSS): XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victims browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. 4. A4 Insecure Direct Object References: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data. 5. A5 Security Misconfiguration: Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date. 6. A6 Sensitive Data Exposure : Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser. 7. A7 Missing Function Level Access Control; Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization. 8. A8 Cross-Site Request Forgery (CSRF): A CSRF attack forces a logged-on victims browser to send a forged HTTP request, including the victims session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victims browser to generate requests the vulnerable application thinks are legitimate requests from the victim. 9. A9 Using Components with Known Vulnerabilities : Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts. 10. A10 Unvalidated Redirects and Forwards: Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper

validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.