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
|
