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"
| Line 1: | Line 1: | ||
| − | This talk discusses input validation design choices and recommends practices that | + | 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 | + | 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 | + | 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 | + | input validation. Architectural |
| − | refactoring, | + | refactoring, arguably mundane, but often neglected, will be employed to get rid of the |
worst code smells. For those who favor life on the bleeding edge, the | worst code smells. For those who favor life on the bleeding edge, the | ||
discussion also ambles into some more tentative territory. | discussion also ambles into some more tentative territory. | ||
Revision as of 20:39, 30 March 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. Architectural refactoring, arguably mundane, but often neglected, will be employed to get rid of the worst code smells. For those who favor life on the bleeding edge, the discussion also ambles into some more tentative territory.
