Home page logo

webappsec logo WebApp Sec mailing list archives

Re: SQL Injection
From: Stephen de Vries <stephen () corsaire com>
Date: Wed, 16 Jun 2004 09:56:19 +0100

From: Frank Knobbe <frank () knobbe us>
Date: 15 June 2004 21:09:33 BST
To: webappsec () securityfocus com
Cc: mark () curphey com, Stephen de Vries <stephen () corsaire com>
Subject: Re: SQL Injection

But the basic fact is that you have TWO checkpoints. Checking data on
input and checking data on output.

From a practical point of view I understand what you're saying, but from a design point of view, I think there are more elegant ways of achieving this. When designing an application as a whole, it would be possible to implement both input and output validation since it's quite easy to determine which functions output data to which components. But when design starts becoming more modular, each function or component needs more independence and won't necessarily know where it's output is going to be used. Since it doesn't know where the output will be used, it can't know how it should be validated and/or sanitized. But I think we agree that the data must be validated at some point, so instead of validating it in a function just before output, it would be more elegant to define another function that accepts the data and validates it as input. For example, consider a function that reads a text file and displays the contents to a browser. Using output validation the process would be (and please excuse my atrocious pseudo-code):

Function: ReadAndDisplay
1.  Read file
2.  Sanitize the output for viewing in a browser
3.  Return output

Using only input validation to achieve the same thing, the function would be split into two distinct functions each dealing with it's own processing context:

Function: ReadFile
1.  Read file
2. Return output (since this functions purpose is to read a file and return the contents, irrespective of where that content is used - the output is not validated)

Function: DisplayToBrowser
1.  Read input (from function: ReadFile)
2. Sanitize input (and since this function deals with browsers, it knows that it should sanitize input for display in a browser)
3.  Return output

Both achieve the same result, but I believe the second example is a better solution in large applications since it is more modular and draws clearer boundaries between data processing contexts.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]