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

Difference between revisions of "AppSecEU08 Input validation: the Good, the Bad and the Ugly"

From OWASP
Jump to: navigation, search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
This talk discusses input validation design choices and recommends practices that will give you a fighting chance to survive architectural decay as the application matures.
+
This talk discusses input validation design choices and recommends practices that provide developers a fighting chance to survive architectural decay as an application matures.
  
The OWASP 2004 Top Ten adviced to never trust user input. The advice is sound, but led many web application developer to write code that is a maintenance nightmare and insecure. This talk argues that the enthusiasm for input validation must be tempered by a resolve to eliminate code duplication to maintain sanity and security. I will show that it is possible to do so, even in the face of apparently conflicting objectives: usability and protection against malicious users.
+
The OWASP 2004 Top Ten adviced never to trust user input. Although fundamentally sound, it led to many maintenance nightmares and insecure web applications. This talk argues that the enthusiasm for input validation must be tempered by a resolve to eliminate code duplication to maintain sanity and security. I will show this is possible, even in the face of apparently conflicting objectives, namely usability and protection against malicious users.
  
The talk's discussion takes place against the backdrop of a case study
+
The discussion is illustrated by a case study
 
of a well-intentioned but flawed attempt at implementing meticulous
 
of a well-intentioned but flawed attempt at implementing meticulous
input validation and goes on to suggest some architectural
+
input validation. The application's validation code is scattered throughout the code base.
refactoring, often mundane but often neglected, to get rid of the
+
I investigate what can be done to improve the code.
worst code smells. For those who favor life on the bleeding edge, the
+
However, writing elegant validation code is found to be very hard in current mainstream technologies, so I also explore some promising alternatives.
discussion also ambles into some more tentative territory.
 

Latest revision as of 19:41, 22 April 2008

This talk discusses input validation design choices and recommends practices that provide developers a fighting chance to survive architectural decay as an application matures.

The OWASP 2004 Top Ten adviced never to trust user input. Although fundamentally sound, it led to many maintenance nightmares and insecure web applications. This talk argues that the enthusiasm for input validation must be tempered by a resolve to eliminate code duplication to maintain sanity and security. I will show this is possible, even in the face of apparently conflicting objectives, namely usability and protection against malicious users.

The discussion is illustrated by a case study of a well-intentioned but flawed attempt at implementing meticulous input validation. The application's validation code is scattered throughout the code base. I investigate what can be done to improve the code. However, writing elegant validation code is found to be very hard in current mainstream technologies, so I also explore some promising alternatives.