From: vertigo <ve...@pa...> - 2002-06-18 20:51:26
|
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 |