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

[Matt W. <wi...@ce...>]

On Tuesday 18 June 2002 15:51, vertigo wrote:
>    I am uncertain of the experience with and opinions toward OO
> that the group may have. =20

There's nothing really wrong with OO.  I believe the bulk of our target l=
anguages=20
support it (perl,python,asp,C++, Java, PHP, ruby) albeit Perl's OOP is di=
rty -- its pretty
much "stapled on", but it does work (though, if Perl6 ever becomes non-va=
porware, this'll change).

> 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:

Here's where I begin to disagree.   The bulk of your web app developers (=
commercial or personal)
are not going to want tons of object instantiations and umpteen method in=
vocations just to get one lousy
stinking "cleaned" piece of data.

>
> public class myServlet extends HTTPServlet {
>
> =09Filter f =3D new Filter("/usr/local/filters/etc/filters.xml");
>
> =09public void doGet(HttpServletRequest req,
> =09=09=09  HttpServletResponse res) throws
> ServletException,
> =09=09=09=09=09=09=09  IOException
> =09{
> =09=09Integer userID;
> =09=09String userName;
>
1 > =09=09f.addParameter("username", req.getParameter("username"),
 > "java.lang.String");
2 > =09=09f.addParameter("userID", req.getParameter("userID"),
> "java.lang.Integer");
3 > =09=09f.addScanner(new
4 > OwaspScanner("/usr/local/filters/etc/signatures.xml.gz"));
>
5 > =09=09f.filter();
6 > =09=09f.scanParameter("username");
7 > =09=09userName =3D f.getFilteredParameter("username");
8 > =09=09userID =3D f.getFilteredParameter("userID");
> =09=09(....)
> =09}
> }
>

8 bloody lines for two pieces of data!!  At this point, I'd say "to hell =
with it", and do one of two things:

1) I'm ignorant or I don't care.  I just don't do anything.
2)  Write up a simple function for each type of data I'm handling and cal=
l it when I need it.
     Or, use simple constructs my language provides.
     E.g., PHP provides a mysql_escape_string() function to escape out th=
e nasties.
     Or, I'll use the "?" syntax in my perl or python apps.. if some mist=
yped data gets in there,=20
=09my db will catch it, error out, and I'll just die() the script.

What I'd like to be able with this toolkit is this:
(And shucks folks, we'll even do it with OO in  my own whacked out pseudo=
 code)

--begin myIncludeFile.inc --
=09myFilterRuleset =3D new FilterRuleSetObject( some_data )
=09=09// I don't know what we'll use, to me XML is just a PITA
=09myFilter =3D new Filter(myFilterRuleSet)
--end myIncludeFile.inc--

--begin myapp--
require myIncludeFile.inc

//say we want to retrieve and store some data in a database
user_id =3D (int) myFilter(request.param('user_id'), __SQL_FILTER__)
message =3D myFilter(request.param('message'), __SQL_FILTER__)

/* store this data */
(...)

//say we want to retrieve and display some data to the user
/* grab data from database */

print myFilter(db_result['message'], __XSS_FILTER__, __HTML_FILTER__)

--end myapp--

There, very simple to use in the app.  I'll only define my filter ruleset=
 once (since it may be complicated), or as needed.
I quickly get my cleaned data and let the filter object handle all the sc=
anning and cleaning based upon the filter ruleset object.


>
>
>    The filter class is fairly complicated, and this is a sim-
> plification.  I think, however, it shows the basics.

Sure, it may be complicated but it shouldn't be complicated or a hassle t=
o use.
 =20
> 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. =20

Sure, we all do that. =20

> I want to avoid the lowest-common-
> denominator approach to development.=20
> 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

Yes,  to hell with all of the people who may be new to this and are looki=
ng
for something helpful to start.
Seriously, it should be easy to use.  Good documentation will then make i=
t
easy to at least understand the concepts involved with filtering the data=
=2E
Hopefully this will lead to a more learned individual, at least wrt data =
filtering.

>    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. =20

I 100% disagree..  By allowing range checking, if I understand what you m=
ean correctly,=20
 we are beginning to write the developer's project for=20
him/her.  We can't predict what the user wants.  There would have to be a=
 lot of flexibility to
do this right.  It just makes it more complicated.

If my usernames should be between 8 to 20 characters, then I should check=
 that myself, not
tell the filter to do it for me.   =20

> 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.

Nothing that  a simple cast, where applicable, can handle.
Doing otherwise will only suffice to make the project an albatross.

Most people aren't using strongly typed high level programming languages
to write web applications (anymore).  Although I would concede that Java =
is becoming more
popular, especially wrt JSP.

-matt

--=20
Matthew Wirges
Developer, CERIAS Incident Response Database
wi...@ce... -- [765]49-67707