[Owasp-input-api-developers] Re: start of a Java implemenation

[Ingo S. <in...@in...>]

Hi folks,

I read the filter classes and here are some general remarks/questions:

1. On which stage should the filter framework bang the malicious input?
  e.g. is it intended to work on the protocol layer or on some layer visi=
ble
  to the user?
2. If it is intended to work on a low-level layer (that's what I assume),=
 why
   do you want to support charsets?
   Nearly any protocol works *without* charset support on a lower level.
   If you want a "transparent" filter framework (i.e. without or with ver=
y low
   performance loss) then it would be best to spare the charset stuff and=
 work
   on a byte[] level. If you make the assumption that the charset *IS* se=
ven
   bit on the filter stage, then you will make your life much easier and =
more
   fun... :o)
3. If it is really necessary to use charsets for some reason, I would pro=
pose
   to use an own impl (at least in java), since the default java impl is =
*way*
   to slow.
4. what I really like is the "goodChars" approach.
   The filter framework should only allow for a predefined set of good ch=
ars.
   If the range of chars must be widened, then it would be best to define=
 some
   "character classes" in terms of goodChars arrays and combine them with
  logical or. If you use the "char" in the classical sense, then it reall=
y is
  a byte, hence the goodChars are goodBytes
5. the pattern matching should work with raw byte patterns too, i.e. only=
 a=20
   one-byte-charset should be used. any "charset" stuff can be simulated
   with certain "goodBytesPatterns" (e.g. the byte pattern for the German
   a-umlaut ä in a given charset, lets say ISO 8859-1)
6. the pattern matching should reject a byte sequence immediately if it f=
inds
   some byte / byte pattern that is not allowed.
7. for a proposal of a filter chaining mechanism see=20
   org.owasp.util.filter (OCL) This framework is *NOT* intended only to f=
ilter
   out some patterns, but to mutate the filtered stuff.
  For the filtering project I would propose *ONLY* to reject invalid inpu=
t,
  since modification is a potential risk (the modification mechanism coul=
d be
  abused)

((( (only remarks regarding code style)
 8. Why do you always access members within methods with "this.{member}"?
   "this." is the implicit default, hence superfluous and should be ommit=
ted.
9. Vector should be considered to be obsolete and not be used in favor of=
=20
   ArrayList (as well as Enumeration et al.)
 )))

Kind regards

Ingo