OSG Dev Notes - Revision history

Medelibero: /* To Do */

2006-12-21T15:56:35Z

‎To Do

Medelibero: /* To Do */

2006-12-17T08:07:41Z

‎To Do

Medelibero: /* To Do */

2006-12-16T17:35:01Z

‎To Do

Dinis.cruz: /* Proposed Architecture */

2006-12-09T00:23:05Z

‎Proposed Architecture

Dinis.cruz: /* Proposed Architecture */

2006-12-09T00:16:22Z

‎Proposed Architecture

Dinis.cruz: /* To Do */

2006-12-09T00:07:20Z

‎To Do

Dinis.cruz: /* Proposed Architecture */

2006-12-09T00:05:20Z

‎Proposed Architecture

Medelibero: /* Proposed Architecture */

2006-12-08T17:25:06Z

‎Proposed Architecture

Medelibero at 17:21, 8 December 2006

2006-12-08T17:21:27Z

Medelibero at 17:18, 8 December 2006

2006-12-08T17:18:44Z

@@ Line 4: / Line 4: @@
 * Add as many examples of vulnerablilties as possible
 * Add different types of Navigation attacks.
 == Hacme Bank conversion ==

@@ Line 2: / Line 2: @@
 == To Do ==
 * Add as many examples of vulnerablilties as possible
-* Add different types of Navigation
+* Add different types of Navigation attacks.
 == Hacme Bank conversion ==

@@ Line 9: / Line 9: @@
 * Add some AJAX
 ** This will use the WebServices (or not).
 == Hacme Bank conversion ==

@@ Line 10: / Line 10: @@
 ** This will use the WebServices (or not).
 * Integrate it with the Web Goats tests being created by the other AoC project
 == Proposed Architecture ==

@@ Line 13: / Line 13: @@
 == Proposed Architecture ==
 For future development the following idea is proposed.  Create an interface that is used for all vulnerabilities.  When a user selects a vulnerability they will have the option how they wish it to be implemented (web service, normal page, etc...) they can chose one or more options for the implementation.
 Each interface will have to be able to tell the front end what form fields it needs and also an area to handle the request back.
 The reason for doing this is so that we only have to code one vulnerability and use it in many different places easier.
 '''Downsides'''
 *Potentially to complex for the payoff.
-*There could be a better way to do it while still following the DRY principle.
+*There could be a better way to do it while still following the [http://en.wikipedia.org/wiki/Don't_repeat_yourself DRY principle].
 == Integration with WebGoat and other Web Technologies ==

← Older revision		Revision as of 00:05, 9 December 2006
Line 24:		Line 24:
	*Potentially to complex for the payoff.		*Potentially to complex for the payoff.
	*There could be a better way to do it while still following the DRY principle.		*There could be a better way to do it while still following the DRY principle.
		+
		+
		+
		+	== Integration with WebGoat and other Web Technologies ==
		+
		+	The idea here is to be able to use Site Generator's capability to create dynamic websites (based on XML files) with the vulnerabilities developed for Web Goat
		+
		+	Basically what I want is to be able to use Web Goat's vulnerabilities in OSG (OWASP Site Generator), which leverages the work done by WebGoat developers and exposes OSG users to a wider set of issues.
		+
		+	Since the idea here is to reuse code, the Web Goat OSG pages will need to be served from an Apache server. So what needs to be done for this to work is for somebody to write an Java/Apache equivalent to the C# Httpmodule/IIS that is used on the current OSG vulnerabilities
		+
		+	This component is quite simple since all that is basically doing (at this stage) is receiving all requests made to a particular website (lets say http://sitegenerator/websiteA/pageb.jsp ) and going to OSG (via TCP) and asking "what page does this request maps to?". OSG goes to the current loaded XML file and if there is a match it says: "that page maps to 'vulnerabilityDatabase\SQLInjectionExample\BlindSQLInjection.jsp"). with that information the apache server (in this example) will load that jsp page and send it to the client (without rewiring the URL (which is what creates the illusion of virtual OSG websites)).
		+
		+	Since the current WebGoat pages are designed for lessons, I expect to be some tweaking on its code , but the idea here is to keep the development of integrating these two projects to the minimum.

← Older revision		Revision as of 17:25, 8 December 2006
Line 12:		Line 12:

	== Proposed Architecture ==		== Proposed Architecture ==
		+	For future development the following idea is proposed. Create an interface that is used for all vulnerabilities. When a user selects a vulnerability they will have the option how they wish it to be implemented (web service, normal page, etc...) they can chose one or more options for the implementation.
		+
		+
		+	Each interface will have to be able to tell the front end what form fields it needs and also an area to handle the request back.
		+
		+
		+	The reason for doing this is so that we only have to code one vulnerability and use it in many different places easier.
		+
		+
		+	'''Downsides'''
		+	*Potentially to complex for the payoff.
		+	*There could be a better way to do it while still following the DRY principle.

← Older revision		Revision as of 17:21, 8 December 2006
Line 1:		Line 1:
	Back to [[OWASP_SiteGenerator]] main page		Back to [[OWASP_SiteGenerator]] main page
		+
		+	== To Do ==
		+	* Add a bunch of vulnerablilties
		+	* Add different types of Navigation
		+	* Add web services
		+	** Main goal of this is to have web services in there that show that web services can't be trusted and are another place for attacks.
		+	* Add some AJAX
		+	** This will use the WebServices.
		+	* Integrate it with the Web Goats tests being created by the other AoC project
		+	* Implement Hacme Bank into OSG (this will take care of the web services item also)
		+
		+	== Proposed Architecture ==

← Older revision		Revision as of 17:18, 8 December 2006
Line 1:		Line 1:
−	Back to [[OWASP_SiteGenerator ~~Site Generator~~]]	+	Back to [[OWASP_SiteGenerator]] main page