This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

OWASP Unified Pentesting Framework

From OWASP
Revision as of 17:55, 11 March 2015 by KateHartmann (talk | contribs) (Created page with "=Main= <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">link=</div> {| style="padding: 0;margin:0;margin-top:10px;t...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
OWASP Project Header.jpg

Instructions are in RED text and should be removed from your document by deleting the text with the span tags. This document is intended to serve as an example of what is required of an OWASP project wiki page. The text in red serves as instructions, while the text in black serves as an example. Text in black is expected to be replaced entirely with information specific to your OWASP project.

OWASP Unified Pentesting Framework

Unified Pen-testing Framework (UPF) is intended to help pen-testers to run multiple vulnerability scanning tools under the same framework so that the tools need not be run as individual processes and also gives a final clubbed Pentest report.

Description

Our project aims to provide a framework for Pen-testers in order to run a wide variety of tools under an umbrella framework. The tangible deliverable for this project will be a python framework, which will provide the basis of execution for our tool and which will output a report for aiding the Pen-tester with the creation of his Pen-testing report.

Licensing

This program is free software: you can redistribute it and/or modify it under the terms of the Apache 2.0 License

Project Resources

This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.

Github


Project Leader

Arjun TU

Related Projects

This is where you can link to other OWASP Projects that are similar to yours.


Classifications

Project Type Files TOOL.jpg
Incubator Project Owasp-breakers-small.png
Owasp-defenders-small.png
Apache 2.0

News and Events

This is where you can provide project updates, links to any events like conference presentations, Project Leader interviews, case studies on successful project implementations, and articles written about your project.

Many projects have "Frequently Asked Questions" documents or pages. However, the point of such a document is not the questions. The point of a document like this are the answers. The document contains the answers that people would otherwise find themselves giving over and over again. The idea is that rather than laboriously compose and post the same answers repeatedly, people can refer to this page with pre-prepared answers. Use this space to communicate your projects 'Frequent Answers.'


Contributors

The success of OWASP is due to a community of enthusiasts and contributors that work to make our projects great. This is also true for the success of your project. Be sure to give credit where credit is due, no matter how small! This should be a brief list of the most amazing people involved in your project. Be sure to provide a link to a complete list of all the amazing people in your project's community as well.

Arjun TU

A project roadmap is the envisioned plan for the project. The purpose of the roadmap is to help others understand where the project is going as well as areas that volunteers may contribute. It gives the community a chance to understand the context and the vision for the goal of the project. Additionally, if a project becomes inactive, or if the project is abandoned, a roadmap can help ensure a project can be adopted and continued under new leadership. Roadmaps vary in detail from a broad outline to a fully detailed project charter. Generally speaking, projects with detailed roadmaps have tended to develop into successful projects. Some details that leaders may consider placing in the roadmap include: envisioned milestones, planned feature enhancements, essential conditions, project assumptions, development timelines, etc. You are required to have at least 4 milestones for every year the project is active.

Roadmap

The road map for the project is written below. For a more organised document regarding the project, please checkout the pdf: https://www.dropbox.com/s/hpbhy0gqnt42f1g/Initial%20Project%20Doc.pdf?dl=0

All the details regarding the initial phase of the project has been included in the document (including Roadmap, Scope of the project etc...)

Phase 1: Alpha: 1. Basic framework completion. 2. Addition of new tools possible. 3. Basic exception handling. Alpha renaissance: 1. Extensive real world testing of Alpha. 2. Stable re-release of Alpha by squashing bugs reported.

Beta: 1. Building blocks for advanced framework. 2. Extensive exception handling. 3. Static report generation.4. Streamlining of basic features. Beta renaissance: 1. Extensive real world testing of Beta. 2. Stable re-release of Beta by squashing bugs reported. Gamma: 1. Extensive rework of stable Beta renaissance code for optimization. 2. Extensive re-documentation based on user requests and developer needs. Gamma renaissance: 1. Extensive real world testing of Gamma. 2. Stable re-release of Gamma by squashing all the bugs reported. ((Phase 1 completed. UPF V1 released.))Phase 2: Alpha: 1. Parallel execution of tools added (Efficient Multiprocessing). 2. Grouping of tools into specific categories for selected execution. Alpha renaissance: 1. Extensive real world testing. 2. Bugs reported are fixed. 3. Tool subjected to various stress tests and worked on until it pass the stress tests. Beta: 1. Encapsulation of each and every tool, thereby making it impossible for it to affect any other tool, or the main tool. 2. Easy integration of any number of tools by the user. 3. Streamlining of features added in alpha.4. Dynamic user report creation. Beta renaissance:- 1. Extensive real world testing. 2. Bugs reported are fixed. 3. Tool subjected to various stress tests and worked on until it pass the stress tests. Gamma: 1. Extensive rework of stable Beta renaissance code for optimization. 2. Extensive re-documentation based on user requests. Gamma renaissance:- 1. Extensive real world testing. 2. Bugs reported are fixed. 3. Tool subjected to various stress tests and worked on until it passed the stress tests. ((Phase 2 completed. UPF V2 release.))Phase 3: Alpha: 1. Basic GUI elements. Alpha renaissance: 1. Community feedback on GUI taken. 2. GUI modified according to community feedback. 3. Real world testing done. 4. Bugs reported are squashed. Beta: 1. Intermediate level GUI done. Beta renaissance: 1. Community feedback on GUI taken. 2. GUI modified according to community feedback. 3. Real world testing.4. Bugs reported are squashed. Gamma: 1. GUI fully done. All functionalities of tool can be accessed through GUI. Gamma renaissance: 1. GUI further optimized for speed. 2. Using community feedback, GUI aesthetics improved. 3. Real world testing. 4. Bugs reported are squashed. ((Phase 3 Completed. UPF V3 released.))

Getting Involved

Our project aims to provide a framework for Pen-testers in order to run a wide variety of tools under an umbrella framework. The tangible deliverable for this project will be a python framework, which will provide the basis of execution for our tool and which will output a report for aiding the Pen-tester with the creation of his Pen-testing report.