Testing Guide 4.0

Total Page:16

File Type:pdf, Size:1020Kb

Testing Guide 4.0 1 Testing Guide 4.0 Project Leaders: Matteo Meucci and Andrew Muller Creative Commons (CC) Attribution Share-Alike Free version at http://www.owasp.org 2 THE ICONS BELOW REPRESENT WHAT YOU ARE FREE: OTHER VERSIONS ARE AVAILABLE IN PRINT FOR THIS BOOK TITLE. To Share - to copy, distribute and ALPHA: “Alpha Quality” book content is a transmit the work working draft. Content is very rough and in development until the next level of publishing. To Remix - to adapt the work BETA: “Beta Quality” book content is the next highest level. Content is still in development UNDER THE FOLLOWING CONDITIONS: until the next publishing. RELEASE: “Release Quality” book content Attribution. You must attribute the work is the highest level of quality in a book title’s in the manner specified by the author or lifecycle, and is a final product. licensor (but not in any way that suggests that they endorse you or your use of the work). Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. ALPHA BETA RELEASE The Open Web Application Security Project (OWASP) is a worldwide free and open com- munity focused on improving the security of application software. Our mission is to make application security “visible”, so that people and organizations can make informed decisions about application security risks. Every one is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a 501c3 not-for-profit charitable organization that ensures the ongoing availability and support for our work. Project Leaders: Matteo Meucci and Andrew Muller 1 Testing Guide Foreword - By Eoin Keary Testing Guide Foreword The problem of insecure software is perhaps the most important technical challenge of our time. The 0 dramatic rise of web applications enabling business, social networking etc has only compounded the requirements to establish a robust approach to writing and securing our Internet, Web Applications and Data. Foreword by Eoin Keary, OWASP Global Board The problem of insecure software is perhaps the most important technical challenge of our time. The dramatic rise of web appli- cations enabling business, social networking etc has only com- pounded the requirements to establish a robust approach to writ- ing and securing our Internet, Web Applications and Data. At The Open Web Application Security Project (OWASP), we’re trying to make the world a place where insecure software is the anomaly, not the norm. The OWASP Testing Guide has an import- ant role to play in solving this serious issue. It is vitally important that our approach to testing software for security issues is based on the principles of engineering and science. We need a consis- tent, repeatable and defined approach to testing web applications. A world without some minimal standards in terms of engineering and technology is a world in chaos. It goes without saying that you can’t build a secure application without performing security testing on it. Testing is part of a wider approach to building a secure system. Many software develop- ment organizations do not include security testing as part of their standard software development process. What is even worse is that many security vendors deliver testing with varying degrees of quality and rigor. Security testing, by itself, isn’t a particularly good stand alone Why OWASP? measure of how secure an application is, because there are an in- finite number of ways that an attacker might be able to make an Creating a guide like this is a huge undertaking, requiring the ex- application break, and it simply isn’t possible to test them all. We pertise of hundreds of people around the world. There are many can’t hack ourselves secure and we only have a limited time to test different ways to test for security flaws and this guide captures and defend where an attacker does not have such constraints. the consensus of the leading experts on how to perform this test- ing quickly, accurately, and efficiently. OWASP gives like minded In conjunction with other OWASP projects such as the Code review security folks the ability to work together and form a leading prac- Guide, the Development Guide and tools such as OWASP ZAP, this tice approach to a security problem. is a great start towards building and maintaining secure applica- tions. The Development Guide will show your project how to archi- The importance of having this guide available in a completely free tect and build a secure application, the Code Review Guide will tell and open way is important for the foundations mission. It gives you how to verify the security of your application’s source code, anyone the ability to understand the techniques used to test for and this Testing Guide will show you how to verify the security of common security issues. Security should not be a black art or your running application. I highly recommend using these guides closed secret that only a few can practice. It should be open to all as part of your application security initiatives. and not exclusive to security practitioners but also QA, Developers 2 Testing Guide Foreword - By Eoin Keary and Technical Managers. The project to build this guide keeps this terms of the application and its use cases. expertise in the hands of the people who need it - you, me and anyone that is involved in building software. This guide is best viewed as a set of techniques that you can use to find different types of security holes. But not all the techniques This guide must make its way into the hands of developers and are equally important. Try to avoid using the guide as a checklist, software testers. There are not nearly enough application security new vulnerabilities are always manifesting and no guide can be experts in the world to make any significant dent in the overall an exhaustive list of “things to test for”, but rather a great place problem. The initial responsibility for application security must to start. fall on the shoulders of the developers, they write the code. It shouldn’t be a surprise that developers aren’t producing secure The Role of Automated Tools code if they’re not testing for it or consider the types of bugs which introduce vulnerability. There are a number of companies selling automated security anal- ysis and testing tools. Remember the limitations of these tools so that you can use them for what they’re good at. As Michael Keeping this information up to date is a critical aspect of this guide Howard put it at the 2006 OWASP AppSec Conference in Seattle, project. By adopting the wiki approach, the OWASP community “Tools do not make software secure! They help scale the process can evolve and expand the information in this guide to keep pace and help enforce policy.” with the fast moving application security threat landscape. Most importantly, these tools are generic - meaning that they are This Guide is a great testament to the passion and energy our not designed for your custom code, but for applications in general. members and project volunteers have for this subject. It shall cer- That means that while they can find some generic problems, they tainly help change the world a line of code at a time. do not have enough knowledge of your application to allow them to detect most flaws. In my experience, the most serious security Tailoring and Prioritizing issues are the ones that are not generic, but deeply intertwined in your business logic and custom application design. You should adopt this guide in your organization. You may need to tailor the information to match your organization’s technologies, These tools can also be seductive, since they do find lots of poten- processes, and organizational structure. tial issues. While running the tools doesn’t take much time, each one of the potential problems takes time to investigate and ver- In general there are several different roles within organizations ify. If the goal is to find and eliminate the most serious flaws as that may use this guide: quickly as possible, consider whether your time is best spent with automated tools or with the techniques described in this guide. • Developers should use this guide to ensure that they are produc- Still, these tools are certainly part of a well-balanced application ing secure code. These tests should be a part of normal code and security program. Used wisely, they can support your overall pro- unit testing procedures. cesses to produce more secure code. • Software testers and QA should use this guide to expand the set Call to Action of test cases they apply to applications. Catching these vulnerabil- ities early saves considerable time and effort later. If you’re building, designing or testing software, I strongly encour- age you to get familiar with the security testing guidance in this • Security specialists should use this guide in combination with document. It is a great road map for testing the most common other techniques as one way to verify that no security holes have issues facing applications today, but it is not exhaustive. If you been missed in an application. find errors, please add a note to the discussion page or make the change yourself. You’ll be helping thousands of others who use • Project Managers should consider the reason this guide exists this guide. and that security issues are manifested via bugs in code and de- sign. Please consider joining us as an individual or corporate member so that we can continue to produce materials like this testing guide The most important thing to remember when performing security and all the other great projects at OWASP.
Recommended publications
  • Large-Scale, Automatic XSS Detection Using Google Dorks
    Large-Scale, Automatic XSS Detection using Google Dorks Riccardo Pelizzi Tung Tran Alireza Saberi Abstract XSS Attacks continue to be prevalent today, not only because XSS sanitization is a hard problem in rich- formatting contexts, but also because there are so many potential avenues and so many uneducated developers who forget to sanitize reflected content altogether. In this paper, we present Gd0rk, a tool which em- ploys Google’s advanced search capabilities to scan for websites vulnerable to XSS. It automatically generates Figure 1: CVE vulnerabilities for 2010 and maintains a database of parameters to search, and uses heuristics to prioritize scanning hosts which are degrees of client-side support with a primarily server- more likely to be vulnerable. Gd0rk includes a high- side XSS defense [37, 23, 31]. However, the diffusion of throughput XSS scanner which reverse engineers and ap- such methods remains limited: hybrid methods require proximates XSS filters using a limited number of web re- support from both clients and servers. Since the party quests and generates working exploits using HTML and that is most directly affected by an XSS attack is the user JavaScript context-aware rules. who accesses a vulnerable server, client-side protections The output produced by the tool is not only a remark- are thus desirable (despite their limitation to so-called re- ably vast database of vulnerable websites along with flected XSS) and have been developed [29,4, 17, 11]. working XSS exploits, but also a more compact repre- However, client-side defenses are no definitive solution sentation of the list in the form of google search terms, either: IE8 regular-expression based approach is easy whose effectiveness has been tested during the search.
    [Show full text]
  • SEO Footprints
    SEO Footprints Brought to you by: Jason Rushton Copyright 2013 Online - M a r k e t i n g - T o o l s . c o m Page 1 Use these “Footprints” with your niche specific keywords to find Backlink sources. Some of the footprints below have already been formed into ready made search queries. TIP* If you find a footprint that returns the results you are looking for, there is no need to use the rest in that section. For example if I am looking for wordpress sites that allow comments and the search query “powered by wordpress” “YOUR YOUR KEYWORDS” returns lots of results there is no need to use all of the others that target wordpress sites as a lot of them will produce similar results. I would use one or two from each section. You can try them out and when you find one you like add it to your own list of favourites. Blogs “article directory powered by wordpress” “YOUR YOUR KEYWORDS” “blog powered by wordpress” “YOUR YOUR KEYWORDS” “blogs powered by typepad” “YOUR YOUR KEYWORDS” “YOURYOUR KEYWORDS” inurl:”trackback powered by wordpress” “powered by blogengine net 1.5.0.7” “YOUR YOUR KEYWORDS” “powered by blogengine.net” “YOUR YOUR KEYWORDS” “powered by blogengine.net add comment” “YOUR YOUR KEYWORDS” “powered by typepad” “YOUR YOUR KEYWORDS” “powered by wordpress” “YOUR YOUR KEYWORDS” “powered by wordpress review theme” “YOUR YOUR KEYWORDS” “proudly powered by wordpress” “YOUR YOUR KEYWORDS” “remove powered by wordpress” “YOUR YOUR KEYWORDS” Copyright 2013 Online - M a r k e t i n g - T o o l s .
    [Show full text]
  • Recent Developments in Cybersecurity Melanie J
    American University Business Law Review Volume 2 | Issue 2 Article 1 2013 Fiddling on the Roof: Recent Developments in Cybersecurity Melanie J. Teplinsky Follow this and additional works at: http://digitalcommons.wcl.american.edu/aublr Part of the Law Commons Recommended Citation Teplinsky, Melanie J. "Fiddling on the Roof: Recent Developments in Cybersecurity." American University Business Law Review 2, no. 2 (2013): 225-322. This Article is brought to you for free and open access by the Washington College of Law Journals & Law Reviews at Digital Commons @ American University Washington College of Law. It has been accepted for inclusion in American University Business Law Review by an authorized administrator of Digital Commons @ American University Washington College of Law. For more information, please contact [email protected]. ARTICLES FIDDLING ON THE ROOF: RECENT DEVELOPMENTS IN CYBERSECURITY MELANIE J. TEPLINSKY* TABLE OF CONTENTS Introduction .......................................... ..... 227 I. The Promise and Peril of Cyberspace .............. ........ 227 II. Self-Regulation and the Challenge of Critical Infrastructure ......... 232 III. The Changing Face of Cybersecurity: Technology Trends ............ 233 A. Mobile Technology ......................... 233 B. Cloud Computing ........................... ...... 237 C. Social Networking ................................. 241 IV. The Changing Face of Cybersecurity: Cyberthreat Trends ............ 244 A. Cybercrime ................................. ..... 249 1. Costs of Cybercrime
    [Show full text]
  • Hacking the Master Switch? the Role of Infrastructure in Google's
    Hacking the Master Switch? The Role of Infrastructure in Google’s Network Neutrality Strategy in the 2000s by John Harris Stevenson A thesis submitteD in conformity with the requirements for the Degree of Doctor of Philosophy Faculty of Information University of Toronto © Copyright by John Harris Stevenson 2017 Hacking the Master Switch? The Role of Infrastructure in Google’s Network Neutrality Strategy in the 2000s John Harris Stevenson Doctor of Philosophy Faculty of Information University of Toronto 2017 Abstract During most of the decade of the 2000s, global Internet company Google Inc. was one of the most prominent public champions of the notion of network neutrality, the network design principle conceived by Tim Wu that all Internet traffic should be treated equally by network operators. However, in 2010, following a series of joint policy statements on network neutrality with telecommunications giant Verizon, Google fell nearly silent on the issue, despite Wu arguing that a neutral Internet was vital to Google’s survival. During this period, Google engaged in a massive expansion of its services and technical infrastructure. My research examines the influence of Google’s systems and service offerings on the company’s approach to network neutrality policy making. Drawing on documentary evidence and network analysis data, I identify Google’s global proprietary networks and server locations worldwide, including over 1500 Google edge caching servers located at Internet service providers. ii I argue that the affordances provided by its systems allowed Google to mitigate potential retail and transit ISP gatekeeping. Drawing on the work of Latour and Callon in Actor– network theory, I posit the existence of at least one actor-network formed among Google and ISPs, centred on an interest in the utility of Google’s edge caching servers and the success of the Android operating system.
    [Show full text]
  • Webové Diskusní Fórum
    MASARYKOVA UNIVERZITA F}w¡¢£¤¥¦§¨ AKULTA INFORMATIKY !"#$%&'()+,-./012345<yA| Webové diskusní fórum BAKALÁRSKÁˇ PRÁCE Martin Bana´s Brno, Jaro 2009 Prohlášení Prohlašuji, že tato bakaláˇrskápráce je mým p ˚uvodnímautorským dílem, které jsem vy- pracoval samostatnˇe.Všechny zdroje, prameny a literaturu, které jsem pˇrivypracování používal nebo z nich ˇcerpal,v práci ˇrádnˇecituji s uvedením úplného odkazu na pˇríslušný zdroj. V Brnˇe,dne . Podpis: . Vedoucí práce: prof. RNDr. JiˇríHˇrebíˇcek,CSc. ii Podˇekování Dˇekujivedoucímu prof. RNDr. JiˇrímuHˇrebíˇckovi,CSc. za správné vedení v pr ˚ubˇehucelé práce a trpˇelivostpˇrikonzutacích. Dále dˇekujicelému kolektivu podílejícímu se na reali- zaci projektu FEED za podnˇetnépˇripomínkya postˇrehy. iii Shrnutí Bakaláˇrskápráce se zabývá analýzou souˇcasnýchdiskusních fór typu open-source a vý- bˇerem nejvhodnˇejšíhodiskusního fóra pro projekt eParticipation FEED. Další ˇcástpráce je zamˇeˇrenána analýzu vybraného fóra, tvorbu ˇceskéhomanuálu, ˇceskélokalizace pro portál a rozšíˇrenípro anotaci pˇríspˇevk˚u. Poslední kapitola je vˇenovánanasazení systému do provozu a testování rozšíˇrení pro anotaci pˇríspˇevk˚u. iv Klíˇcováslova projekt FEED, eParticipation, diskusní fórum, portál, PHP, MySQL, HTML v Obsah 1 Úvod ...........................................3 2 Projekt eParticipation FEED .............................4 2.1 eGovernment ...................................4 2.2 Úˇcastníciprojektu FEED .............................4 2.3 Zamˇeˇreníprojektu FEED .............................5 2.4 Cíl
    [Show full text]
  • Google Dorks: Use Cases and Adaption Study
    Google dorks: Use cases and Adaption study UNIVERSITY OF TURKU Department of Future Technologies Master of Science in Technology Thesis Networked Systems Security October 2020 Reza Abasi Supervisors: Dr. Ali Farooq Dr. Antti Hakkala The originality of this thesis has been checked in accordance with the University of Turku quality assurance system using the Turnitin OriginalityCheck service. i UNIVERSITY OF TURKU Department of Future Technologies Reza Abasi: Google dorks: Use cases and adaption study Master of Science in Technology Thesis, 93 pages. Networked Systems Security October 2020 The information age brought about radical changes in our lives. More and more assets are getting connected to the Internet. On the one hand, the connectivity to this ever-growing network of connected devices and assets (the Internet) precipitates more convenience and access to various resources. However, on the downside, the Internet could be the hotbed for malicious actors like hackers, attackers, and cybercriminals’ communities. Continuous Penetration testing and monitoring of the sites, and forums providing illicit digital products and services is a must-do task nowadays. Advanced searching techniques could be employed for discovering such forums and sites. Google dorks that are utilizing Google’s advanced searching techniques could be applied for such purpose. Google dorks could be used for other areas that we will explain during this thesis in more detail like information gathering, vulnerability detection, etc. The purpose of this thesis is to propose advanced searching techniques that will help cybersecurity professionals in information gathering, reconnaissance, vulnerability detection as well as cyber criminal investigative tasks. Further, a usability study has been conducted to examine the acceptance of these techniques among a group of cybersecurity professionals.
    [Show full text]
  • HTTP Header Analysis
    HTTP Header Analysis Author:Roland Zegers Master System and Network Engineering University of Amsterdam [email protected] August 31, 2015 Abstract Many companies are busy finding new solutions for detecting the growing amount of malware that is propagated over the Internet. A lot of anti-malware developers use the unique signature of the payload as a detection mechanism. Others look at the communication channels. Research has been done to see what information HTTP headers can provide. Different aspects of headers have been investigated in order to track malware: header sizes, type errors or the presence or absence of certain headers. This information is then used to create a fingerprint or signature. The goal of this research was to look at order of HTTP request headers to see if it is possible to determine if malware is present. Although the header order of malware is very irregular, it does not stand out when compared to HTTP headers from regular traffic. Websites have their own header order as well as programs that communicate over HTTP like Windows updates and anti-virus solutions. Some websites request special services or offer specific content. This leads to the insertion of extra headers, like security-, SOAP- or experimental headers, which create inconsistency in the order of the headers. As a result of this, it is unfeasible to use header order to reliably identify systems or malware. 1 Contents 1 Introduction 3 1.1 Rationale . .3 1.2 Related research . .3 2 Research Questions 4 2.1 Problem definition . .4 2.2 Research Questions . .4 3 Request headers 4 3.1 HTTP header structure .
    [Show full text]
  • Phpbb 3.3 Proteus Documentation
    phpBB 3.3 Proteus Documentation Edited by Dominik Dröscher and Graham Eames phpBB 3.3 Proteus Documentation by Dominik Dröscher and Graham Eames Copyright © 2005 phpBB Group Abstract The detailed documentation for phpBB 3.3 Proteus. Table of Contents 1. Quick Start Guide ..................................................................................................... 1 1. Requirements ..................................................................................................... 1 2. Installation ......................................................................................................... 2 2.1. Introduction ............................................................................................ 3 2.2. Requirements .......................................................................................... 3 2.3. Administrator details .............................................................................. 3 2.4. Database settings .................................................................................... 3 2.5. Configuration file ................................................................................... 5 2.6. Advanced settings .................................................................................. 5 2.7. Final Steps .............................................................................................. 5 2.8. Supporting the phpBB organization ....................................................... 6 3. General settings ................................................................................................
    [Show full text]
  • Symbols Administrators
    Index ■Symbols administrators. See also administering $access_check variable, 209 admin user (Drupal), 11–12 & (ampersand) in path aliases, 84 approving comments in WordPress, 396 <br /> (break tag), 476 auditing, 296–297 <!—more—> tag, 475–477 Advanced Editing mode (WordPress) <!—noteaser—> tag, 476 Advanced options in, 405–406, 408–409 >> (breadcrumb links), 159 previewing posts in, 409 ? (question mark) in path aliases, 84 using Custom Fields, 409 / (slash) in path aliases, 84 Advanced Mode (phpBB) announcement forum permissions in, 304 ■A group permissions in, 307 paraccess setting permission in, 303–304 accessing database abstraction layer, user permissions in, 305 335–338 Aggregator module, 61–64 Drupal rules for, 36–38 adding feeds, 63 Image Assist module settings for, 111 categorizing feeds, 64 rights for database servers, 6 function of, 61–62 site, 8–9 identifying feeds for subscription, 62 activating setting permissions, 64 group blocks, 132 viewing options for feeds, 64 IImage Browser plug-in, 410–411 aggregators, 375 RSS Link List plug-in, 424 aliased domains, 191 WP-DB Backup plug-in, 490 aliases to Drupal paths, 84–85 Admin Configuration panel (phpBB 2.0), 235, ampersand (in path aliases), 84 236–237 animation in posts, 287 administering. See also administrators; announcement forums, 247, 304 Database Administration module announcements Administer Nodes permission, 135 global, 287 administrative password for WordPress, permissions for, 270–271 389–390 removing, 315 blocks, 39–40 Anonymous User role (Drupal), 34, 35 Drupal
    [Show full text]
  • Code Review Guide
    CODE REVIEW GUIDE 3.0 RELEASE Project leaders: Mr. John Doe and Jane Doe Creative Commons (CC) Attribution Free Version at: https://www.owasp.org 1 2 F I 1 Forward - Eoin Keary Introduction How to use the Code Review Guide 7 8 10 2 Secure Code Review 11 Framework Specific Configuration: Jetty 16 2.1 Why does code have vulnerabilities? 12 Framework Specific Configuration: JBoss AS 17 2.2 What is secure code review? 13 Framework Specific Configuration: Oracle WebLogic 18 2.3 What is the difference between code review and secure code review? 13 Programmatic Configuration: JEE 18 2.4 Determining the scale of a secure source code review? 14 Microsoft IIS 20 2.5 We can’t hack ourselves secure 15 Framework Specific Configuration: Microsoft IIS 40 2.6 Coupling source code review and penetration testing 19 Programmatic Configuration: Microsoft IIS 43 2.7 Implicit advantages of code review to development practices 20 2.8 Technical aspects of secure code review 21 2.9 Code reviews and regulatory compliance 22 5 A1 3 Injection 51 Injection 52 Blind SQL Injection 53 Methodology 25 Parameterized SQL Queries 53 3.1 Factors to Consider when Developing a Code Review Process 25 Safe String Concatenation? 53 3.2 Integrating Code Reviews in the S-SDLC 26 Using Flexible Parameterized Statements 54 3.3 When to Code Review 27 PHP SQL Injection 55 3.4 Security Code Review for Agile and Waterfall Development 28 JAVA SQL Injection 56 3.5 A Risk Based Approach to Code Review 29 .NET Sql Injection 56 3.6 Code Review Preparation 31 Parameter collections 57 3.7 Code Review Discovery and Gathering the Information 32 3.8 Static Code Analysis 35 3.9 Application Threat Modeling 39 4.3.2.
    [Show full text]
  • Multi-Step Scanning in ZAP Handling Sequences in OWASP ZAP
    M.Sc. Thesis Master of Science in Engineering Multi-step scanning in ZAP Handling sequences in OWASP ZAP Lars Kristensen (s072662) Stefan Østergaard Pedersen (s072653) Kongens Lyngby 2014 DTU Compute Department of Applied Mathematics and Computer Science Technical University of Denmark Matematiktorvet Building 303B 2800 Kongens Lyngby, Denmark Phone +45 4525 3031 [email protected] www.compute.dtu.dk Summary English This report presents a solution for scanning sequences of HTTP requests in the open source penetration testing tool, Zed Attack Proxy or ZAP. The report documents the analysis, design and implementation phases of the project, as well as explain how the different test scenarios were set up and used for verification of the functionality devel- oped in this project. The proposed solution will serve as a proof-of-concept, before being integrated with the publically available version of the application. Dansk Denne rapport præsenterer en løsning der gør det muligt at skanne HTTP fore- spørgsler i open source værktøjet til penetrationstest, Zed Attack Proxy eller ZAP. Rapporten dokumenterer faserne for analyse, design og implementering af løsningen, samt hvordan forskellige test scenarier blev opstillet og anvendt til at verificere funk- tionaliteten udviklet i dette projekt. Den foreslåede løsning vil fungere som et proof- of-concept, før det integreres med den offentligt tilgængelige version af applikationen. ii Preface This thesis was prepared at the department of Applied Mathematics and Computer Science at the Technical University of Denmark in fulfilment of the requirements for acquiring a M.Sc. degree in respectivly Computer Science and Engineering, and in Digital Media Engineering. Kongens Lyngby, September 5.
    [Show full text]
  • Evaluation and Testing of Several Free/Open Source Web Vulnerability Scanners
    The 10th Conference for Informatics and Information Technology (CIIT 2013) The 10 th Conference for Informatics and Information Technology (CIIT 2013) EVALUATION AND TESTING OF SEVERAL FREE/OPEN SOURCE WEB VULNERABILITY SCANNERS Nataša Šuteva Dragi Zlatkovski, Aleksandra Mileva Faculty of Computer Science, UGD Faculty of Computer Science, UGD Štip, Macedonia Štip, Macedonia ABSTRACT significant number of vulnerabilities in test applications [1, 4, 12, 14, 15, 22]. Bau et al [1], testing eight WVSs, showed that Web Vulnerability Scanners (WVSs) are software tools for WVSs need to be improved in detection of the “stored” and identifying vulnerabilities in web applications. There are second-order forms of XSS and SQLI, and in understanding commercial WVSs, free/open source WVSs, and some of active content and scripting languages. Khoury [7, 8] companies offer them as a Software-as-a-Service. In this analyzed three state-of –art black box WVSs against stored paper, we test and evaluate six free/open source WVSs using SQLI, and their results showed that stored (persistent) SQLI the web application WackoPicko with many known are not detected even when these automated scanners are vulnerabilities, primary for false negative rates. taught to exploit the vulnerability. They propose also a set of recommendations for increasing a detection rate in WVSs for I. INTRODUCTION this type of vulnerability. Doupé et al [4] tested eleven WVSs, Our everyday live heavily depends on using different web and found that eight out of sixteen vulnerabilities were not applications, as web e-mail clients, web instant messaging detected by any of the used scanners. They discuss also a clients, Voice over IP services, e-learning portals, social critical limitations of current WVSs, lack of better support for networks, electronic banking, e-commerce platforms, etc.
    [Show full text]