Thread: [Owasp-input-api-developers] OO, Dumb Programmes, and Strongly-Typed Languages

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Group,

   Yesterday's meeting was very helpful, but I would like to
address a few concerns before we continue.  These are: object
orientation, our target audience, and data-types.  As a Java
programmer and proponent of object-oriented development I would
like development to be as object-oriented as possible.  I also
disagree with the assumption that the programmers we are
targetting as potential users of this API are ignorant of fun-
damental persistence issues like not being able to fit a 4000
character string into a 255 character VARCHAR field.  This leads
to my third concern--data types.  This may seem too "language-
dependent" to most people, but even when I use Perl, I filter my
fields to make sure they match the types in the database.

   I am uncertain of the experience with and opinions toward OO
that the group may have.  The word "function" seemed to pervade
the conversation, as in "wrap _EVERYTHING_ with one of our fun-
ctions." The design I had in mind involved adding unfiltered
parameters to a filter object, calling the filter() method, then
retrieving filtered parameters from it, as in the following
lines of code:

public class myServlet extends HTTPServlet {

	Filter f = new Filter("/usr/local/filters/etc/filters.xml");

	public void doGet(HttpServletRequest req,
			  HttpServletResponse res) throws
ServletException,
							  IOException
	{
		Integer userID;
		String userName;

		f.addParameter("username", req.getParameter("username"),
"java.lang.String");
		f.addParameter("userID", req.getParameter("userID"),
"java.lang.Integer");
		f.addScanner(new
OwaspScanner("/usr/local/filters/etc/signatures.xml.gz"));

		f.filter();
		f.scanParameter("username");
		userName = f.getFilteredParameter("username");
		userID = f.getFilteredParameter("userID");
		(....)
	}
}

A UML representation would look something like:

|-------------------|                       |--------------|
|      Filter       |			    |  Parameter   |
|-------------------|			    |--------------|
|#parameters[]      |1		       0..* |              |
|#filteredparams[]  |---------------------->|              |
|-------------------|                       |--------------|
|+addParameter()    |
|+filter()          |
|+getFilteredParam()|
---------------------

   The filter class is fairly complicated, and this is a sim-
plification.  I think, however, it shows the basics.  From a
cross-platform perspective, the returned value does not have to
be strongly typed.  In a Perl implementation, the accessors
would just return a scalar.  It would, however, be a scalar that
has been filtered, and perhaps modified to fit into a field of
a certain type w/in the application's RDBMS.  On a side note, I
think we need to separate the concepts of validation and sig-
nature scanning, with systems dedicated to both processes.
   One of the more significant goals I believe we should set is
creating the public interface to the API (e.g. canonicalize(),
scan(), validate(), etc.).

   Having been a SQL Server developer previous to being a Java
developer, as well as having development experience with mySQL,
PostgreSQL, Oracle, and BerkeleyDB (it's simple, but useful in
a pinch) I have a decent understanding of persistence that not
all developers may posess.  This being said, I have tried to
look at this application from the perspective of what __I__
would like to see in it, and not necessarily what the average
user would like to see.  I want to avoid the lowest-common-
denominator approach to development.  We are not making a tool
for checking one's eBay auctions.  We are developing a tool for
programmers who are interested in and dedicated to the security
of their applications--and a tool that can be easily modified
without having to send the entire app back to QA for a week (or
longer) when one decides to scan for a new signature.

   One of the capabilities that Mark Curphey expressed interest
in is range checking.  This implies data-types.  A good article
on the subject of data-type validation (please excuse the Java
focus) can be found at:

http://www.javaworld.com/javaworld/jw-09-2000/jw-0908-validation.html

I would like this product to have the capability of fine-grained
and course-grained data-type validation, and I have already
assured him that it will.  Data-type validation does not mean an
all-inclusive class for checking data-types.  It involves
creating a collection of validation classes, each intended to
validate a well-defined set of types (e.g. the set of SQL Server
6.5 types, and the set of SQL Server 7 types, and the set of ANSI
C types).  This may seem too language- or platform-specific to
some, but I believe data-type validation is at the heart of this
application, and signature scanning secondary.

I hope this has clarified my concerns, and perhaps some of my own
design goals.

Nathan

Thread: [Owasp-input-api-developers] OO, Dumb Programmes, and Strongly-Typed Languages

owasp-input-api-developers