OWASP Validation Documentation - Revision history

Khalid: /* Centralized Design */

2007-01-29T15:07:56Z

‎Centralized Design

Esheridan: /* Centralized Design */

2006-10-12T13:14:38Z

‎Centralized Design

Esheridan: /* J2EE Filter */

2006-10-11T15:51:22Z

‎J2EE Filter

Esheridan at 15:38, 11 October 2006

2006-10-11T15:38:49Z

Kyle.dent: /* Negative Security */

2006-09-20T04:10:08Z

‎Negative Security

Esheridan at 20:14, 12 September 2006

2006-09-12T20:14:12Z

Show changes

← Older revision		Revision as of 15:07, 29 January 2007
Line 18:		Line 18:

	The validation engine should be centralized such that every module in the application adheres to the validation rules and principles		The validation engine should be centralized such that every module in the application adheres to the validation rules and principles
		+	<nowiki>--~~~~Insert non-formatted text here
		+	----
		+
		+	----
		+	<nowiki>
		+	== Insert non-formatted text here ==
		+	[[Image:[[Media:Example.jpg]]<math>'''Insert formula here'''''''Italic text''[[Link title]]''</math>]]</nowiki></nowiki>

	===Simplistic API===		===Simplistic API===

@@ Line 17: / Line 17: @@
 ===Centralized Design===
-The validation engine should be centralized such that every module in the application adheres to the validation rules and principals
+The validation engine should be centralized such that every module in the application adheres to the validation rules and principles
 ===Simplistic API===

← Older revision		Revision as of 15:51, 11 October 2006
Line 77:		Line 77:

	J2EE filters provide the ability to intercept, view, and modify both the request and associated response for the requesting client. Filters are inserted and executed by the J2EE container's deployment descriptor (web.xml) file. For example, if an HTTP request for a JSP page hits our Apache web server, the request is sent to Tomcat for processing. Before Tomcat executes the code inside of the JSP, the request must be passed along a chain of J2EE filters. One such chain would essentially be our input validation engine. Here, we can simply validate the request and take the appropriate action before the request ever hits the intended web application.		J2EE filters provide the ability to intercept, view, and modify both the request and associated response for the requesting client. Filters are inserted and executed by the J2EE container's deployment descriptor (web.xml) file. For example, if an HTTP request for a JSP page hits our Apache web server, the request is sent to Tomcat for processing. Before Tomcat executes the code inside of the JSP, the request must be passed along a chain of J2EE filters. One such chain would essentially be our input validation engine. Here, we can simply validate the request and take the appropriate action before the request ever hits the intended web application.
		+
		+	An excellent article on developing a straight-forward J2EE validation filter can be found at http://www.owasp.org/index.php/How_to_add_validation_logic_to_HttpServletRequest.

	===.NET HTTPModule===		===.NET HTTPModule===

@@ Line 3: / Line 3: @@
 ==Abstract==
-Correctly implementing an input validation mechanism for a custom application is extremely difficult. It is then inevitable that large web applications will fall victim to this class of vulnerability. Therefore, a developer should have a clear understanding of how to successfully design and implement a reusable input validation mechanism for their applications. The OWASP Validation Documentation attempts to fulfill this requirement by providing the necessary design principals as well as an example implementation. This document is structured such that if a developer were to incorporate all of the presented design principals, then the result will be a complete and reusable input validation engine.
+Correctly implementing an input validation mechanism for a custom application is extremely difficult. It is then inevitable that large web applications will fall victim to this class of vulnerability. Therefore, a developer should have a clear understanding of how to successfully design and implement a reusable input validation mechanism for their applications. The OWASP Validation Documentation attempts to fulfill this requirement by providing the necessary design principles as well as an example implementation. This document is structured such that if a developer were to incorporate all of the presented design principles, then the result will be a complete and reusable input validation engine.
-=Design Principals=
+=Design Principles=
-==A2.1	Design Principal Overview==
+==A2.1	Design Principle Overview==
 The most overlooked module in web applications is the input validation mechanism. Unfortunately, most developers are either unaware of the consequences or simply find developing input validation mechanisms “too hard”. For the former, I refer you to the 'Guide'. The latest version at the time of writing is 2.01. There exists an entire section related to input validation and the potential consequences of faulty validation mechanisms. The most important concept that a reader should take away from the 'Data Validation' section of 'The Guide' is that a weak input validation mechanism “leads to almost all of the major vulnerabilities in applications, such as interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows” (The Guide, pg 173). Two obvious additions when discussing web application validation is that of Cross Site Scripting and SQL Injection. These attacks are constantly taking place and are often cited in the OWASP Application Security News section (http://www.owasp.org). Ever hear of a bank reporting that they've had several thousand credit card numbers stolen? Ever hear of the 'MySpace' worm? These issues would not exist had application developers implemented input validation correctly. Therefore, it is the goal of this document to provide a clear and detailed set of principals that should be incorporated in the development of an application specific input validation mechanism.
@@ Line 220: / Line 220: @@
 ==Overview==
-At this point, the reader should have a solid understanding of the design principals that should be incorporated into an input validation engine. While Stinger is certainly capable of being implemented in production services, the major goal of Stinger was to provide an example implementation of these six design principals. By reviewing the implementation of Stinger, the reader will fully understand how all of the design principals are tied together.
+At this point, the reader should have a solid understanding of the design principles that should be incorporated into an input validation engine. While Stinger is certainly capable of being implemented in production services, the major goal of Stinger was to provide an example implementation of these six design principles. By reviewing the implementation of Stinger, the reader will fully understand how all of the design principles are tied together.
-==How the Design Principals are Implemented==
+==How the design principles are Implemented==
 ===Positive Security Model===

@@ Line 33: / Line 33: @@
 ===Negative Security===
-When the positive security model becomes to open, the developer should be able to implement a negative security model.
+When the positive security model becomes too open, the developer should be able to implement a negative security model.
 =Positive Security Model=