OWASP - User contributions [en]

SpoC 007 - OWASP Site Generator

2008-03-29T21:21:33Z

Adl:

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

'''Project Contributors''': Abby Levenberg, Boris Maletic

'''Project coordinator''': Dinis Cruz

'''Project Progress''': 20% Complete, [[SpoC 007 - OWASP Site Generator - Progress Page|Progress Page]]

== OWASP Site Generator ==

=== Executive Summary ===

OWASP Site Generator is a great tool, but it could be even better and more widespread. There’s a lot room for improvements to both its functionality and user experience. The way I see it, main user needs to be addressed and specific development objectives for the next release of OWASP Site Generator would be the following.

=== User Needs ===

* Create multiple types of sites easily
* Track and analyze requests easily
* Change the look and feel of the resulting sites easily
* Create sites for multiple web backend technologies easily
* Learn how to use OWASP Site Generator easily

=== Development Objectives ===

* Create a vulnerability library that can be used for web services, HTML forms, AJAX, etc. instead of having to craft the same attack for each
* Add support for logging of all received requests, as well as querying resulting log files
* "Templatize" the code generation process, so it can support skinning of the resulting sites
* "Templatize" the code generation process, so it can support different backend web technologies
* Fix all significant defects in the current release of OWASP Site Generator
* Redesign the GUI to make it more efficient and user friendly
* Create a smooth setup program which would install both client and server components as effortlessly as possible
* Write documentation and articles about it
* Make the development process open to the public and, hopefully, driven by its feedback from day one

=== Development Links ===
'''[http://www.owasp.org/index.php/OWASP_OSG_Functional_Spec OWASP Site Generator Functional Specification]'''

'''[http://www.owasp.org/index.php/OWASP_OSG_User_Stories OWASP Site Generator User Stories]'''

'''[https://www.owasp.org/images/8/8a/OWASP_SiteGenerator_V2_DFD.pdf OWASP Site Generator Data Flow Diagram]'''

SpoC 007 - OWASP Site Generator

2008-03-29T21:19:42Z

Adl:

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

'''Project Contributors''': Abby Levenberg, Boris Maletic

'''Project coordinator''': Dinis Cruz

'''Project Progress''': 20% Complete, [[SpoC 007 - OWASP Site Generator - Progress Page|Progress Page]]

== OWASP Site Generator ==

=== Executive Summary ===

OWASP Site Generator is a great tool, but it could be even better and more widespread. There’s a lot room for improvements to both its functionality and user experience. The way I see it, main user needs to be addressed and specific development objectives for the next release of OWASP Site Generator would be the following.

=== User Needs ===

* Create multiple types of sites easily
* Track and analyze requests easily
* Change the look and feel of the resulting sites easily
* Create sites for multiple web backend technologies easily
* Learn how to use OWASP Site Generator easily

=== Development Objectives ===

* Create a vulnerability library that can be used for web services, HTML forms, AJAX, etc. instead of having to craft the same attack for each
* Add support for logging of all received requests, as well as querying resulting log files
* "Templatize" the code generation process, so it can support skinning of the resulting sites
* "Templatize" the code generation process, so it can support different backend web technologies
* Fix all significant defects in the current release of OWASP Site Generator
* Redesign the GUI to make it more efficient and user friendly
* Create a smooth setup program which would install both client and server components as effortlessly as possible
* Write documentation and articles about it
* Make the development process open to the public and, hopefully, driven by its feedback from day one

=== Development Links ===
'''[http://www.owasp.org/index.php/OWASP_OSG_Functional_Spec OWASP Site Generator Functional Specification]'''

'''[http://www.owasp.org/index.php/OWASP_OSG_User_Stories OWASP Site Generator User Stories]'''

'''[OWASP_SiteGenerator_V2_DFD.pdf OWASP Site Generator Data Flow Diagram]'''

File:OWASP SiteGenerator V2 DFD.pdf

2008-03-29T21:16:46Z

Adl:

SpoC 007 - OWASP Site Generator

2008-03-29T21:14:51Z

Adl:

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

'''Project Contributors''': Abby Levenberg, Boris Maletic

'''Project coordinator''': Dinis Cruz

'''Project Progress''': 20% Complete, [[SpoC 007 - OWASP Site Generator - Progress Page|Progress Page]]

== OWASP Site Generator ==

=== Executive Summary ===

OWASP Site Generator is a great tool, but it could be even better and more widespread. There’s a lot room for improvements to both its functionality and user experience. The way I see it, main user needs to be addressed and specific development objectives for the next release of OWASP Site Generator would be the following.

=== User Needs ===

* Create multiple types of sites easily
* Track and analyze requests easily
* Change the look and feel of the resulting sites easily
* Create sites for multiple web backend technologies easily
* Learn how to use OWASP Site Generator easily

=== Development Objectives ===

* Create a vulnerability library that can be used for web services, HTML forms, AJAX, etc. instead of having to craft the same attack for each
* Add support for logging of all received requests, as well as querying resulting log files
* "Templatize" the code generation process, so it can support skinning of the resulting sites
* "Templatize" the code generation process, so it can support different backend web technologies
* Fix all significant defects in the current release of OWASP Site Generator
* Redesign the GUI to make it more efficient and user friendly
* Create a smooth setup program which would install both client and server components as effortlessly as possible
* Write documentation and articles about it
* Make the development process open to the public and, hopefully, driven by its feedback from day one

=== Development Links ===
'''[http://www.owasp.org/index.php/OWASP_OSG_Functional_Spec OWASP Site Generator Functional Specification]'''

'''[http://www.owasp.org/index.php/OWASP_OSG_User_Stories OWASP Site Generator User Stories]'''

'''[http://www.owasp.org/index.php/OWASP_OSG_dfd OWASP Site Generator Data Flow Diagram]'''

OWASP OSG User Stories

2008-03-29T21:13:29Z

Adl:

'''[https://www.owasp.org/index.php/SpoC_007_-_OWASP_Site_Generator Back to SpoC 007 OSG page]'''

== Story #1 ==
Bob works for a small security consulting firm and has recently been given the job of teaching a local bank's developers common web security issues. Instead of using an arbitrary website that has vulnerabilities in it he decides to make a copy of the bank's site and adding common vulnerabilities. However, Bob is stretched thin and doesn't want to write all these vulnerabilities by hand. He goes to OWASP because he knows of a project that he thinks will help him (OWASP Site Generator) looking at the project's area he thinks it will fit his needs. Bob installs OSG and sets it up. Once OSG is installed Bob launches htdig and crawls three levels deep of the bank's site and saves it to disk. Launching OSG Bob creates a new site using the desktop application and then interlaces the pages with the vulnerabilities he wishes to showcase in the training.

At the training Bob launches both the server and client applications and using the desktop client points the OSG site to use the custom layout he created. Using the custom template the vulnerabilities sank into the developers at the local bank. Also, because of his great performance Bob got a raise.

== Story #2 ==
Boris is a OWASP volunteer and finds out about this cool new web attack. He remembers that OWASP has a tool called OWASP Site Generator(OSG) that has a library of web attacks/vulnerabilities that can be included in web sites and web services. Boris checks to see if this new attack is in the library of possible attacks, it is not. He loads up his copy of Visual C# Express and imports in the IVulnerability interface into VS, so, that he can create this new web attack. After creating the attack and testing it on his local machine. He submits the source and a description to OWASP for approval and addition into the OSG attack library. The attack gets approved and included into the library for other people to use. Boris is also added to the list of people who have contributed to the library with links to what specifically he has added.

== Story #3 ==
Boris is an entry-level ASP.NET developer, clueless about web security. But he has a gut-feeling that his web apps are not very secure. So he wants to learn more about security using this new cool tool, OSG. He cannot implement the IVulnerability interface, because he doesn't quite get the whole interfaces idea, and even if he did, he wouldn't know what to put in the implementation. Therefore, he completely relies on the existing vulnerabilities library built by other people and made publicly available by OWASP. Specifically, there are only two types of attacks that he's actually interested in: XSS and SQL injection. So, he opens the OSG client and starts a new project (site). He wants to add two pages to it, one for XSS, and another for SQL injection. But he has no idea how to do it. He then hits “create site” and a default template is used to generate a site with links to the XSS and SQL Injection examples he specified as being available for his site.

OWASP OSG User Stories

2008-03-29T21:00:43Z

Adl: New page: == Story #1 == Bob works for a small security consulting firm and has recently been given the job of teaching a local bank's developers common web security issues. Instead of using an arb...

== Story #1 ==
Bob works for a small security consulting firm and has recently been given the job of teaching a local bank's developers common web security issues. Instead of using an arbitrary website that has vulnerabilities in it he decides to make a copy of the bank's site and adding common vulnerabilities. However, Bob is stretched thin and doesn't want to write all these vulnerabilities by hand. He goes to OWASP because he knows of a project that he thinks will help him (OWASP Site Generator) looking at the project's area he thinks it will fit his needs. Bob installs OSG and sets it up. Once OSG is installed Bob launches htdig and crawls three levels deep of the bank's site and saves it to disk. Launching OSG Bob creates a new site using the desktop application and then interlaces the pages with the vulnerabilities he wishes to showcase in the training.

At the training Bob launches both the server and client applications and using the desktop client points the OSG site to use the custom layout he created. Using the custom template the vulnerabilities sank into the developers at the local bank. Also, because of his great performance Bob got a raise.

== Story #2 ==
Boris is a OWASP volunteer and finds out about this cool new web attack. He remembers that OWASP has a tool called OWASP Site Generator(OSG) that has a library of web attacks/vulnerabilities that can be included in web sites and web services. Boris checks to see if this new attack is in the library of possible attacks, it is not. He loads up his copy of Visual C# Express and imports in the IVulnerability interface into VS, so, that he can create this new web attack. After creating the attack and testing it on his local machine. He submits the source and a description to OWASP for approval and addition into the OSG attack library. The attack gets approved and included into the library for other people to use. Boris is also added to the list of people who have contributed to the library with links to what specifically he has added.

== Story #3 ==
Boris is an entry-level ASP.NET developer, clueless about web security. But he has a gut-feeling that his web apps are not very secure. So he wants to learn more about security using this new cool tool, OSG. He cannot implement the IVulnerability interface, because he doesn't quite get the whole interfaces idea, and even if he did, he wouldn't know what to put in the implementation. Therefore, he completely relies on the existing vulnerabilities library built by other people and made publicly available by OWASP. Specifically, there are only two types of attacks that he's actually interested in: XSS and SQL injection. So, he opens the OSG client and starts a new project (site). He wants to add two pages to it, one for XSS, and another for SQL injection. But he has no idea how to do it. He then hits “create site” and a default template is used to generate a site with links to the XSS and SQL Injection examples he specified as being available for his site.

SpoC 007 - OWASP Site Generator

2008-03-29T20:59:22Z

Adl:

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

'''Project Contributors''': Abby Levenberg, Boris Maletic

'''Project coordinator''': Dinis Cruz

'''Project Progress''': 20% Complete, [[SpoC 007 - OWASP Site Generator - Progress Page|Progress Page]]

== OWASP Site Generator ==

=== Executive Summary ===

OWASP Site Generator is a great tool, but it could be even better and more widespread. There’s a lot room for improvements to both its functionality and user experience. The way I see it, main user needs to be addressed and specific development objectives for the next release of OWASP Site Generator would be the following.

=== User Needs ===

* Create multiple types of sites easily
* Track and analyze requests easily
* Change the look and feel of the resulting sites easily
* Create sites for multiple web backend technologies easily
* Learn how to use OWASP Site Generator easily

=== Development Objectives ===

* Create a vulnerability library that can be used for web services, HTML forms, AJAX, etc. instead of having to craft the same attack for each
* Add support for logging of all received requests, as well as querying resulting log files
* "Templatize" the code generation process, so it can support skinning of the resulting sites
* "Templatize" the code generation process, so it can support different backend web technologies
* Fix all significant defects in the current release of OWASP Site Generator
* Redesign the GUI to make it more efficient and user friendly
* Create a smooth setup program which would install both client and server components as effortlessly as possible
* Write documentation and articles about it
* Make the development process open to the public and, hopefully, driven by its feedback from day one

=== Development Links ===
'''[http://www.owasp.org/index.php/OWASP_OSG_Functional_Spec OWASP Site Generator Functional Specification]'''

'''[http://www.owasp.org/index.php/OWASP_OSG_User_Stories OWASP Site Generator User Stories]'''

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

SpoC 007 - OWASP Site Generator

2008-03-29T20:58:12Z

Adl:

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

'''Project Contributors''': Abby Levenberg, Boris Maletic

'''Project coordinator''': Dinis Cruz

'''Project Progress''': 20% Complete, [[SpoC 007 - OWASP Site Generator - Progress Page|Progress Page]]

== OWASP Site Generator ==

=== Executive Summary ===

OWASP Site Generator is a great tool, but it could be even better and more widespread. There’s a lot room for improvements to both its functionality and user experience. The way I see it, main user needs to be addressed and specific development objectives for the next release of OWASP Site Generator would be the following.

=== User Needs ===

* Create multiple types of sites easily
* Track and analyze requests easily
* Change the look and feel of the resulting sites easily
* Create sites for multiple web backend technologies easily
* Learn how to use OWASP Site Generator easily

=== Development Objectives ===

* Create a vulnerability library that can be used for web services, HTML forms, AJAX, etc. instead of having to craft the same attack for each
* Add support for logging of all received requests, as well as querying resulting log files
* "Templatize" the code generation process, so it can support skinning of the resulting sites
* "Templatize" the code generation process, so it can support different backend web technologies
* Fix all significant defects in the current release of OWASP Site Generator
* Redesign the GUI to make it more efficient and user friendly
* Create a smooth setup program which would install both client and server components as effortlessly as possible
* Write documentation and articles about it
* Make the development process open to the public and, hopefully, driven by its feedback from day one

=== Development Links ===
'''[http://www.owasp.org/index.php/OWASP_OSG_Functional_Spec OWASP Site Generator Functional Specification]'''
'''[http://www.owasp.org/index.php/OWASP_OSG_User_Stories OWASP Site Generator User Stories]'''

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

SpoC 007 - OWASP Site Generator

2008-03-28T00:16:52Z

Adl:

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

'''Project Contributors''': Abby Levenberg, Boris Maletic

'''Project coordinator''': Dinis Cruz

'''Project Progress''': 20% Complete, [[SpoC 007 - OWASP Site Generator - Progress Page|Progress Page]]

== OWASP Site Generator ==

=== Executive Summary ===

OWASP Site Generator is a great tool, but it could be even better and more widespread. There’s a lot room for improvements to both its functionality and user experience. The way I see it, main user needs to be addressed and specific development objectives for the next release of OWASP Site Generator would be the following.

=== User Needs ===

* Create multiple types of sites easily
* Track and analyze requests easily
* Change the look and feel of the resulting sites easily
* Create sites for multiple web backend technologies easily
* Learn how to use OWASP Site Generator easily

=== Development Objectives ===

* Create a vulnerability library that can be used for web services, HTML forms, AJAX, etc. instead of having to craft the same attack for each
* Add support for logging of all received requests, as well as querying resulting log files
* "Templatize" the code generation process, so it can support skinning of the resulting sites
* "Templatize" the code generation process, so it can support different backend web technologies
* Fix all significant defects in the current release of OWASP Site Generator
* Redesign the GUI to make it more efficient and user friendly
* Create a smooth setup program which would install both client and server components as effortlessly as possible
* Write documentation and articles about it
* Make the development process open to the public and, hopefully, driven by its feedback from day one

=== Development Links ===
'''[http://www.owasp.org/index.php/OWASP_OSG_Functional_Spec OWASP Site Generator Functional Specification]'''

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

SpoC 007 - OWASP Site Generator

2008-03-28T00:16:16Z

Adl: /* Why I should be sponsored for the project */

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

'''AoC Candidate''': Boris

'''Project coordinator''': Dinis Cruz

'''Project Progress''': 20% Complete, [[SpoC 007 - OWASP Site Generator - Progress Page|Progress Page]]

== OWASP Site Generator ==

=== Executive Summary ===

OWASP Site Generator is a great tool, but it could be even better and more widespread. There’s a lot room for improvements to both its functionality and user experience. The way I see it, main user needs to be addressed and specific development objectives for the next release of OWASP Site Generator would be the following.

=== User Needs ===

* Create multiple types of sites easily
* Track and analyze requests easily
* Change the look and feel of the resulting sites easily
* Create sites for multiple web backend technologies easily
* Learn how to use OWASP Site Generator easily

=== Development Objectives ===

* Create a vulnerability library that can be used for web services, HTML forms, AJAX, etc. instead of having to craft the same attack for each
* Add support for logging of all received requests, as well as querying resulting log files
* "Templatize" the code generation process, so it can support skinning of the resulting sites
* "Templatize" the code generation process, so it can support different backend web technologies
* Fix all significant defects in the current release of OWASP Site Generator
* Redesign the GUI to make it more efficient and user friendly
* Create a smooth setup program which would install both client and server components as effortlessly as possible
* Write documentation and articles about it
* Make the development process open to the public and, hopefully, driven by its feedback from day one

=== Development Links ===
'''[http://www.owasp.org/index.php/OWASP_OSG_Functional_Spec OWASP Site Generator Functional Specification]'''

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

SpoC 007 - OWASP Site Generator - Progress Page

2008-03-28T00:14:13Z

Adl:

'''[https://www.owasp.org/index.php/SpoC_007_-_OWASP_Site_Generator Back to SpoC 007 OSG page]'''

== First Deliverable march 28th 2008 ==
* Developed the hollow framework for the new OSG that includes
** Owasp.Osg.HttpModule - can route any filetypes set in the web.config to it
** Owasp.Osg.Controller - currently only opens a go between connection
** Owasp.Osg.Communication - wraps shared comm classes and houses buffer that shares osg data between remote objects.

SpoC 007 - OWASP Site Generator - Progress Page

2008-03-28T00:12:37Z

Adl:

[https://www.owasp.org/index.php/Sponsored_Projects Back to Sponsored Projects]

== First Deliverable march 28th 2008 ==
* Developed the hollow framework for the new OSG that includes
** Owasp.Osg.HttpModule - can route any filetypes set in the web.config to it
** Owasp.Osg.Controller - currently only opens a go between connection
** Owasp.Osg.Communication - wraps shared comm classes and houses buffer that shares osg data between remote objects.

OWASP OSG Functional Spec

2008-03-28T00:07:24Z

Adl:

'''[https://www.owasp.org/index.php/SpoC_007_-_OWASP_Site_Generator Back to SpoC 007 OSG page]'''

=== Overview ===

Currently it is hard to use OSG. There are a few things we want to improve in OSG to improve usability and increase adoption of OSG.

1) Clean-up the user interface (UI) so it is more intuitive and explorable.
2) Be able to create a library of exploitable code that highlights common mistakes by developers and administrators. This area will be used for dynamically generating websites and web services on the fly. Currently a new page needs to be created for each exploit and transmission method.

=== Components of OSG ===

== Controller ==
This is a desktop application that opens up a port that listens for requests from given web page. The server will take a given site and URL and pass back one of the two following things:
1) The page rendered from a template. The template will be a master page in ASP.Net it will control the layout of the site and the actual content will be defined at the page level.
2) The pages physical file location. Aspx files not needed really as everything will get built on the fly. A few physical files we will need to know are the controls and master pages.

NOTE: It is not uncommon for the old-school OSG devs to refer to this as the desktop client but in reality it is the server.

== Client ==
The client is a web site or virtual folder that has an HTTPModule that talks with the server asking for the proper page to display to the user.

=== UI Changes ===
TBD.

=== Library specification ===

QUESTION: DOES THIS MAKE SENSE, WHAT IS MISSING?
SHOULD THIS BE AN ABSTRACT CLASS INSTEAD?

The following interface will be used for each exploit:

interface IExploit {
/*
* Description: This will be used for returning a form or web page to a calling site.
*
* Precondition: This string will be used on a web page and not something like a web service
*
* Postcondition: The HTML is returned and is ready to be used.
*/
public string getExploitHtml();
/*
* Description: This method will be used for processing the form that was returned in the getExploitHtml call.
*
* Precondition: The HTTPRequest object is accessible
*/
public string processExploitForm(); How are the form values passed on to this method? -Borismaletic 3/12/08 4:00 AM Dude this is a functional spec not a dev-level spec. It is to give you the general idea of how it will work. Nothing here is set in stone, it is just some guidelines. If you want a dev spec I should just create the program myself. -Medelibero 3/16/08 10:11 AM
// Returns a web method defintion for use in a WSDL (is this even possible???)
public string getWSDLDefinition(); Is this the idea here to create some test form that invokes the service based on this WSDL? Something like what Visual Studio does for asmx files (when opened in the browser)? -Borismaletic 3/12/08 4:01 AM
/*
* Description: This handle the processing of the Web Service Method.
*/
public string processWebServiceMethod(); // What parameters does this need? An Array?
}

=== HTTPModule ===
The HTTPModule is the translator between the client and the server. How it works is every site request will initially get handled by the HTTPModule. What the role of the HTTPModule will be is to look at the request and load the proper template and vulnerability values for the request. If the request does not tie to an existing page the default page should be displayed for the folder or site (folder gets precedence). The HTTPModule will also have to figure out in what format the data should be returned. For example if there is a POST request and we need to parse the data the HTTPModule should load the correct form parser and parse the form and return a response.

=== Central Vulnerability Database ===
The central vulnerability database will be an area hosted on a web server (NOTE: Need to find out where this is) that will store all the vulnerabilities/web test cases. The OSG “server” and httpmodule will use this information to show available vulnerabilities and to pull down the information they need. This means that this central area will need to have a web service accessible to anyone. Given OWASPs nature this needs to be done with security in mind so that it can withstand any assault since we don’t want some insecure on OWASP.

Along with a web service trusted OWASP members will need to be able to go in and manage the available vulnerabilities. We also need to allow for user submissions. A user submission will not automatically be authorized but instead will be put in a “bucket” for the trusted OWASP members to review and authorize.

=== Interface between the HTTPModule and the Controller ===
Description: This area will describe the interface/communication between the HTTPModule and the Controller. Communication will happen when a new request comes in the HTTPModule will ask the Controller what page and information should actually be rendered.

Details: My thought is to have the two components talk via .Net remoting. In both of the areas there will be a configuration file specifying the port it needs to listen to or connect to. The HTTPModule will initiate the connection and send over the data. The data should be packaged in a class that would look something like.

The httpmodule will send this
Public class osgRequest {
/* This will hold the URI that was request */
public string RequestURI {
// TODO: implement
}
/* This will hold the value from HttpRequest.Method, letting us know if it is a post, get, etc..*/
public string RequestMethod {
// TODO: implement
}
/* This will hold a unique transaction ID, my thoughts are a GUID , the HTTPModule will need
to keep track of valid transaction IDs so it can handle multiple requests*/
public string transactionId {
// TODO: implement
}
}

The controller will return this
public class osgResponse {
/* Holds the transactionID received from the osgRequest object */
public string transactionID {
// TODO: implement
}
/* Specifies the physical file location, if needed */
public string PhysicalFileLocation {
// TODO: Implement
}
/* Holds the template location */
public string DisplayTemplateLocation {
// TODO: implement
}
/* This holds an object that implements the IExploit interface */
public ***** Exploit {
// TODO: implement
}
}

=== Changes Required ===
* New UI and probably a whole new desktop application
* A new HTTPModule that leverages the new vulnerability library
* An eye on making the web site portion of the program working on multiple web servers
* Create a better unified installer that sets up the initial web site along with installing all the bit correctly (this will use WiX)
* Make the websites be able to work under virtual directories
* Investigate the possibility of multiple web sites working at once against a OSG "server"
* Currently whenever a new site has to be created vulnerabilities have to be duplicated and are not dynamically loaded from a library of vulnerabilities. On top of this the pages always have to be manually edited causing for user pain and very little point of OSG being there. A user should be able to supply the pages and using tags like you will find in .Net for adding web-controls they will be able to specify where the vulnerability will be located. That is what the user stories are for..they are examples..-Medelibero 3/16/08 10:10 AM An example of this would be very useful. I am still trying to visualize the solution. -Borismaletic 3/12/08 4:13 AM
* A central store for the majority of vulnerabilities.

'''[https://www.owasp.org/index.php/SpoC_007_-_OWASP_Site_Generator Back to SpoC 007 OSG page]'''

OWASP OSG Functional Spec

2008-03-28T00:04:00Z

Adl:

=== Overview ===

Currently it is hard to use OSG. There are a few things we want to improve in OSG to improve usability and increase adoption of OSG.

1) Clean-up the user interface (UI) so it is more intuitive and explorable.
2) Be able to create a library of exploitable code that highlights common mistakes by developers and administrators. This area will be used for dynamically generating websites and web services on the fly. Currently a new page needs to be created for each exploit and transmission method.

=== Components of OSG ===

== Controller ==
This is a desktop application that opens up a port that listens for requests from given web page. The server will take a given site and URL and pass back one of the two following things:
1) The page rendered from a template. The template will be a master page in ASP.Net it will control the layout of the site and the actual content will be defined at the page level.
2) The pages physical file location. Aspx files not needed really as everything will get built on the fly. A few physical files we will need to know are the controls and master pages.

NOTE: It is not uncommon for the old-school OSG devs to refer to this as the desktop client but in reality it is the server.

== Client ==
The client is a web site or virtual folder that has an HTTPModule that talks with the server asking for the proper page to display to the user.

=== UI Changes ===
TBD.

=== Library specification ===

QUESTION: DOES THIS MAKE SENSE, WHAT IS MISSING?
SHOULD THIS BE AN ABSTRACT CLASS INSTEAD?

The following interface will be used for each exploit:

interface IExploit {
/*
* Description: This will be used for returning a form or web page to a calling site.
*
* Precondition: This string will be used on a web page and not something like a web service
*
* Postcondition: The HTML is returned and is ready to be used.
*/
public string getExploitHtml();
/*
* Description: This method will be used for processing the form that was returned in the getExploitHtml call.
*
* Precondition: The HTTPRequest object is accessible
*/
public string processExploitForm(); How are the form values passed on to this method? -Borismaletic 3/12/08 4:00 AM Dude this is a functional spec not a dev-level spec. It is to give you the general idea of how it will work. Nothing here is set in stone, it is just some guidelines. If you want a dev spec I should just create the program myself. -Medelibero 3/16/08 10:11 AM
// Returns a web method defintion for use in a WSDL (is this even possible???)
public string getWSDLDefinition(); Is this the idea here to create some test form that invokes the service based on this WSDL? Something like what Visual Studio does for asmx files (when opened in the browser)? -Borismaletic 3/12/08 4:01 AM
/*
* Description: This handle the processing of the Web Service Method.
*/
public string processWebServiceMethod(); // What parameters does this need? An Array?
}

=== HTTPModule ===
The HTTPModule is the translator between the client and the server. How it works is every site request will initially get handled by the HTTPModule. What the role of the HTTPModule will be is to look at the request and load the proper template and vulnerability values for the request. If the request does not tie to an existing page the default page should be displayed for the folder or site (folder gets precedence). The HTTPModule will also have to figure out in what format the data should be returned. For example if there is a POST request and we need to parse the data the HTTPModule should load the correct form parser and parse the form and return a response.

=== Central Vulnerability Database ===
The central vulnerability database will be an area hosted on a web server (NOTE: Need to find out where this is) that will store all the vulnerabilities/web test cases. The OSG “server” and httpmodule will use this information to show available vulnerabilities and to pull down the information they need. This means that this central area will need to have a web service accessible to anyone. Given OWASPs nature this needs to be done with security in mind so that it can withstand any assault since we don’t want some insecure on OWASP.

Along with a web service trusted OWASP members will need to be able to go in and manage the available vulnerabilities. We also need to allow for user submissions. A user submission will not automatically be authorized but instead will be put in a “bucket” for the trusted OWASP members to review and authorize.

=== Interface between the HTTPModule and the Controller ===
Description: This area will describe the interface/communication between the HTTPModule and the Controller. Communication will happen when a new request comes in the HTTPModule will ask the Controller what page and information should actually be rendered.

Details: My thought is to have the two components talk via .Net remoting. In both of the areas there will be a configuration file specifying the port it needs to listen to or connect to. The HTTPModule will initiate the connection and send over the data. The data should be packaged in a class that would look something like.

The httpmodule will send this
Public class osgRequest {
/* This will hold the URI that was request */
public string RequestURI {
// TODO: implement
}
/* This will hold the value from HttpRequest.Method, letting us know if it is a post, get, etc..*/
public string RequestMethod {
// TODO: implement
}
/* This will hold a unique transaction ID, my thoughts are a GUID , the HTTPModule will need
to keep track of valid transaction IDs so it can handle multiple requests*/
public string transactionId {
// TODO: implement
}
}

The controller will return this
public class osgResponse {
/* Holds the transactionID received from the osgRequest object */
public string transactionID {
// TODO: implement
}
/* Specifies the physical file location, if needed */
public string PhysicalFileLocation {
// TODO: Implement
}
/* Holds the template location */
public string DisplayTemplateLocation {
// TODO: implement
}
/* This holds an object that implements the IExploit interface */
public ***** Exploit {
// TODO: implement
}
}

=== Changes Required ===
* New UI and probably a whole new desktop application
* A new HTTPModule that leverages the new vulnerability library
* An eye on making the web site portion of the program working on multiple web servers
* Create a better unified installer that sets up the initial web site along with installing all the bit correctly (this will use WiX)
* Make the websites be able to work under virtual directories
* Investigate the possibility of multiple web sites working at once against a OSG "server"
* Currently whenever a new site has to be created vulnerabilities have to be duplicated and are not dynamically loaded from a library of vulnerabilities. On top of this the pages always have to be manually edited causing for user pain and very little point of OSG being there. A user should be able to supply the pages and using tags like you will find in .Net for adding web-controls they will be able to specify where the vulnerability will be located. That is what the user stories are for..they are examples..-Medelibero 3/16/08 10:10 AM An example of this would be very useful. I am still trying to visualize the solution. -Borismaletic 3/12/08 4:13 AM
* A central store for the majority of vulnerabilities.

OWASP OSG Functional Spec

2008-03-28T00:02:27Z

Adl:

=== Overview ===

Currently it is hard to use OSG. There are a few things we want to improve in OSG to improve usability and increase adoption of OSG.

1) Clean-up the user interface (UI) so it is more intuitive and explorable.
2) Be able to create a library of exploitable code that highlights common mistakes by developers and administrators. This area will be used for dynamically generating websites and web services on the fly. Currently a new page needs to be created for each exploit and transmission method.

=== Components of OSG ===

== Controller ==
This is a desktop application that opens up a port that listens for requests from given web page. The server will take a given site and URL and pass back one of the two following things:
1) The page rendered from a template. The template will be a master page in ASP.Net it will control the layout of the site and the actual content will be defined at the page level.
2) The pages physical file location. Aspx files not needed really as everything will get built on the fly. A few physical files we will need to know are the controls and master pages.

NOTE: It is not uncommon for the old-school OSG devs to refer to this as the desktop client but in reality it is the server.

== Client ==
The client is a web site or virtual folder that has an HTTPModule that talks with the server asking for the proper page to display to the user.

=== UI Changes ===
TBD.

=== Library specification ===

QUESTION: DOES THIS MAKE SENSE, WHAT IS MISSING?
SHOULD THIS BE AN ABSTRACT CLASS INSTEAD?

The following interface will be used for each exploit:

interface IExploit {
/*
* Description: This will be used for returning a form or web page to a calling site.
*
* Precondition: This string will be used on a web page and not something like a web service
*
* Postcondition: The HTML is returned and is ready to be used.
*/
public string getExploitHtml();
/*
* Description: This method will be used for processing the form that was returned in the getExploitHtml call.
*
* Precondition: The HTTPRequest object is accessible
*/
public string processExploitForm(); How are the form values passed on to this method? -Borismaletic 3/12/08 4:00 AM Dude this is a functional spec not a dev-level spec. It is to give you the general idea of how it will work. Nothing here is set in stone, it is just some guidelines. If you want a dev spec I should just create the program myself. -Medelibero 3/16/08 10:11 AM
// Returns a web method defintion for use in a WSDL (is this even possible???)
public string getWSDLDefinition(); Is this the idea here to create some test form that invokes the service based on this WSDL? Something like what Visual Studio does for asmx files (when opened in the browser)? -Borismaletic 3/12/08 4:01 AM
/*
* Description: This handle the processing of the Web Service Method.
*/
public string processWebServiceMethod(); // What parameters does this need? An Array?
}

=== HTTPModule ===
The HTTPModule is the translator between the client and the server. How it works is every site request will initially get handled by the HTTPModule. What the role of the HTTPModule will be is to look at the request and load the proper template and vulnerability values for the request. If the request does not tie to an existing page the default page should be displayed for the folder or site (folder gets precedence). The HTTPModule will also have to figure out in what format the data should be returned. For example if there is a POST request and we need to parse the data the HTTPModule should load the correct form parser and parse the form and return a response.

=== Central Vulnerability Database ===
The central vulnerability database will be an area hosted on a web server (NOTE: Need to find out where this is) that will store all the vulnerabilities/web test cases. The OSG “server” and httpmodule will use this information to show available vulnerabilities and to pull down the information they need. This means that this central area will need to have a web service accessible to anyone. Given OWASPs nature this needs to be done with security in mind so that it can withstand any assault since we don’t want some insecure on OWASP.

Along with a web service trusted OWASP members will need to be able to go in and manage the available vulnerabilities. We also need to allow for user submissions. A user submission will not automatically be authorized but instead will be put in a “bucket” for the trusted OWASP members to review and authorize.

=== Interface between the HTTPModule and the Controller ===
Description: This area will describe the interface/communication between the HTTPModule and the Controller. Communication will happen when a new request comes in the HTTPModule will ask the Controller what page and information should actually be rendered.

Details: My thought is to have the two components talk via .Net remoting. In both of the areas there will be a configuration file specifying the port it needs to listen to or connect to. The HTTPModule will initiate the connection and send over the data. The data should be packaged in a class that would look something like.

The httpmodule will send this
Public class osgRequest {
/* This will hold the URI that was request */
public string RequestURI {
// TODO: implement
}
/* This will hold the value from HttpRequest.Method, letting us know if it is a post, get, etc..*/
public string RequestMethod {
// TODO: implement
}
/* This will hold a unique transaction ID, my thoughts are a GUID , the HTTPModule will need
to keep track of valid transaction IDs so it can handle multiple requests*/
public string transactionId {
// TODO: implement
}
}

The controller will return this
public class osgResponse {
/* Holds the transactionID received from the osgRequest object */
public string transactionID {
// TODO: implement
}
/* Specifies the physical file location, if needed */
public string PhysicalFileLocation {
// TODO: Implement
}
/* Holds the template location */
public string DisplayTemplateLocation {
// TODO: implement
}
/* This holds an object that implements the IExploit interface */
public ***** Exploit {
// TODO: implement
}
}

=== Changes Required ===
1. New UI and probably a whole new desktop application
2. A new HTTPModule that leverages the new vulnerability library
3. An eye on making the web site portion of the program working on multiple web servers
4. Create a better unified installer that sets up the initial web site along with installing all the bit correctly (this will use WiX)
5. Make the websites be able to work under virtual directories
6. Investigate the possibility of multiple web sites working at once against a OSG "server"
7. Currently whenever a new site has to be created vulnerabilities have to be duplicated and are not dynamically loaded from a library of vulnerabilities. On top of this the pages always have to be manually edited causing for user pain and very little point of OSG being there. A user should be able to supply the pages and using tags like you will find in .Net for adding web-controls they will be able to specify where the vulnerability will be located. That is what the user stories are for..they are examples..-Medelibero 3/16/08 10:10 AM An example of this would be very useful. I am still trying to visualize the solution. -Borismaletic 3/12/08 4:13 AM
8. A central store for the majority of vulnerabilities.

OWASP OSG Functional Spec

2008-03-27T23:49:39Z

Adl: New page: OWASP Site Generator Functional Specification Overview Currently it is hard to use OSG. There are a few things we want to improve in OSG to improve usability and increase adoption of OS...

OWASP Site Generator Functional Specification

Overview

Currently it is hard to use OSG. There are a few things we want to improve in OSG to improve usability and increase adoption of OSG.

1) Clean-up the user interface (UI) so it is more intuitive and explorable.
2) Be able to create a library of exploitable code that highlights common mistakes by developers and administrators. This area will be used for dynamically generating websites and web services on the fly. Currently a new page needs to be created for each exploit and transmission method.

Components of OSG

- Controller: this is a desktop application that opens up a port that listens for requests from given web page. The server will take a given site and URL and pass back one of the two following things:
1) The page rendered from a template Where is this template located? Who creates it? What does it look like? -Borismaletic 3/12/08 3:59 AM
- The template will be a master page in ASP.Net it will control the layout of the site and the actual content will be defined at the page level.
2) The pages physical file location I guess this is a plain old aspx file, right? -Borismaletic 3/12/08 4:00 AM
Not needed really as everything will get built on the fly. A few physical files we will need to know are the controls and master pages.

NOTE: It is not uncommon for the old-school OSG devs to refer to this as the desktop client but in reality it is the server.

- Client: The client is a web site or virtual folder that has an HTTPModule that talks with the server asking for the proper page to display to the user.

UI Changes
To be determined by Boris

Library specification

QUESTION: DOES THIS MAKE SENSE, WHAT IS MISSING?
QUESTION: SHOULD THIS BE AN ABSTRACT CLASS INSTEAD?

The following interface will be used for each exploit:

interface IExploit {
/*
* Description: This will be used for returning a form or web page to a calling site.
*
* Precondition: This string will be used on a web page and not something like a web service
*
* Postcondition: The HTML is returned and is ready to be used.
*/
public string getExploitHtml();

/*
* Description: This method will be used for processing the form that was returned in the getExploitHtml call.
*
* Precondition: The HTTPRequest object is accessible
*/
public string processExploitForm(); How are the form values passed on to this method? -Borismaletic 3/12/08 4:00 AM Dude this is a functional spec not a dev-level spec. It is to give you the general idea of how it will work. Nothing here is set in stone, it is just some guidelines. If you want a dev spec I should just create the program myself. -Medelibero 3/16/08 10:11 AM
// Returns a web method defintion for use in a WSDL (is this even possible???)

public string getWSDLDefinition(); Is this the idea here to create some test form that invokes the service based on this WSDL? Something like what Visual Studio does for asmx files (when opened in the browser)? -Borismaletic 3/12/08 4:01 AM

/*
* Description: This handle the processing of the Web Service Method.
*/
public string processWebServiceMethod(); // What parameters does this need? An Array?
}

HTTPModule
Description: The HTTPModule is the translator between the client and the server.
How it works: Every site request will initially get handled by the HTTPModule. What the role of the HTTPModule will be is to look at the request and load the proper template and vulnerability values for the request If vulnerability values are loaded by the HttpModule, does that mean that users don't need/are not able to enter any form (or query string, or whatever) values themselves? -Borismaletic 3/12/08 4:03 AM No, it means we will display back the form for them to submit the data. We are just giving them the way to sploit stuff. -Medelibero 3/16/08 10:10 AM. If the request does not tie to an existing page the default page should be displayed for the folder or site (folder gets precedence). The HTTPModule will also have to figure out in what format the data should be returned. For example if there is a POST request and we need to parse the data the HTTPModule should load the correct form parser and parse the form and return a response.

Central Vulnerability Database
Description: The central vulnerability database will be an area hosted on a web server (NOTE: Need to find out where this is) that will store all the vulnerabilities/web test cases. The OSG “server” and httpmodule will use this information to show available vulnerabilities and to pull down the information they need. This means that this central area will need to have a web service accessible to anyone. Given OWASPs nature this needs to be done with security in mind so that it can withstand any assault since we don’t want some insecure on OWASP.

Along with a web service trusted OWASP members will need to be able to go in and manage the available vulnerabilities. We also need to allow for user submissions. A user submission will not automatically be authorized but instead will be put in a “bucket” for the trusted OWASP members to review and authorize.

Interface between the HTTPModule and the Controller
Description: This area will describe the interface/communication between the HTTPModule and the Controller. Communication will happen when a new request comes in the HTTPModule will ask the Controller what page and information should actually be rendered.

Details: My thought is to have the two components talk via .Net remoting. In both of the areas there will be a configuration file specifying the port it needs to listen to or connect to. The HTTPModule will initiate the connection and send over the data. The data should be packaged in a class that would look something like.

// The httpmodule will send this
Public class osgRequest {
/* This will hold the URI that was request */
public string RequestURI {
// TODO: implement
}
/* This will hold the value from HttpRequest.Method, letting us know if it is a post, get, etc..*/
public string RequestMethod {
// TODO: implement
}
/* This will hold a unique transaction ID, my thoughts are a GUID , the HTTPModule will need
to keep track of valid transaction IDs so it can handle multiple requests*/
Is this some kind of a session identifier, so several requests can be identified as belonging to the same "client" (or "session", or "site")? If so, why is that necessary? If not, what is it for then? -Borismaletic 3/12/08 4:08 AM Yup it is for a session. When dealing with multiple requests it could be needed. If it is not needed then toss it out. If you do not think it is needed keep it out and if we do need it we will add it at that time. -Medelibero 3/16/08 10:07 AM public string transactionId {
// TODO: implement
}
}

// The controller will return this
public class osgResponse {
/* Holds the transactionID received from the osgRequest object */
public string transactionID {
// TODO: implement
}

/* Specifies the physical file location, if needed */
public string PhysicalFileLocation {
// TODO: Implement
}

/* Holds the template location */
So template is a file in the file system. I understand it contains some kind of placeholders that are populated by the HTTP module, right?-Borismaletic 3/12/08 4:11 AM Yea it is an master page in ASP.Net come on man.. -Medelibero 3/16/08 10:08 AM public string DisplayTemplateLocation {
// TODO: implement
}

/* This holds an object that implements the IExploit interface */
public ***** Exploit {
// TODO: implement
}
}

Changes Required

1. New UI and probably a whole new desktop application
2. A new HTTPModule that leverages the new vulnerability library
3. An eye on making the web site portion of the program working on multiple web servers
4. Create a better unified installer that sets up the initial web site along with installing all the bit correctly (this will use WiX)
5. Make the websites be able to work under virtual directories
6. Investigate the possibility of multiple web sites working at once against a OSG "server"
7. Currently whenever a new site has to be created vulnerabilities have to be duplicated and are not dynamically loaded from a library of vulnerabilities. On top of this the pages always have to be manually edited causing for user pain and very little point of OSG being there. A user should be able to supply the pages and using tags like you will find in .Net for adding web-controls they will be able to specify where the vulnerability will be located. That is what the user stories are for..they are examples..-Medelibero 3/16/08 10:10 AM An example of this would be very useful. I am still trying to visualize the solution. -Borismaletic 3/12/08 4:13 AM
8. A central store for the majority of vulnerabilities.

SpoC 007 - OWASP Site Generator

2008-03-27T23:48:51Z

Adl:

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''

'''AoC Candidate''': Boris

'''Project coordinator''': Dinis Cruz

'''Project Progress''': 20% Complete, [[SpoC 007 - OWASP Site Generator - Progress Page|Progress Page]]

== OWASP Site Generator ==

=== Executive Summary ===

OWASP Site Generator is a great tool, but it could be even better and more widespread. There’s a lot room for improvements to both its functionality and user experience. The way I see it, main user needs to be addressed and specific development objectives for the next release of OWASP Site Generator would be the following.

=== User Needs ===

* Create multiple types of sites easily
* Track and analyze requests easily
* Change the look and feel of the resulting sites easily
* Create sites for multiple web backend technologies easily
* Learn how to use OWASP Site Generator easily

=== Development Objectives ===

* Create a vulnerability library that can be used for web services, HTML forms, AJAX, etc. instead of having to craft the same attack for each
* Add support for logging of all received requests, as well as querying resulting log files
* "Templatize" the code generation process, so it can support skinning of the resulting sites
* "Templatize" the code generation process, so it can support different backend web technologies
* Fix all significant defects in the current release of OWASP Site Generator
* Redesign the GUI to make it more efficient and user friendly
* Create a smooth setup program which would install both client and server components as effortlessly as possible
* Write documentation and articles about it
* Make the development process open to the public and, hopefully, driven by its feedback from day one

=== Why I should be sponsored for the project ===

Well, probably because of my past work on AoC (I just hope that won’t be the reason for me not to be sponsored :)

=== Development Links ===
'''[http://www.owasp.org/index.php/OWASP_OSG_Functional_Spec OWASP Site Generator Functional Specification]'''

'''[http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Selection Back to SpoC 007 Selection page]'''