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

[Alex R. <al...@ne...>]

> 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
> visible to the user?

have a look through the archives and try to find the "vision document". I=
t=20
describes our boundary-filtering concept. The BaseFilter class is just=20
that, a superclass for filters that will be placed at various boundries.

> 2. If it is intended to work on a low-level layer (that's what I assume=
),
> why do you want to support charsets?

canonicalization. We need to be sure that what we're filtering is in the=20
charset we intend our filters to be handling, otherwise we open up=20
ourselves to Unicode problems.

> 3. If it is really necessary to use charsets for some reason, I would
> propose 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
> chars. If the range of chars must be widened, then it would be best to
> define some "character classes" in terms of goodChars arrays and combin=
e
> them with logical or. If you use the "char" in the classical sense, the=
n
> it really is a byte, hence the goodChars are goodBytes

eh. canonicalization before flitering makes this moot.

> 6. the pattern matching should reject a byte sequence immediately if it
> finds some byte / byte pattern that is not allowed.

that's what the "good chars" stuff is for.

> 7. for a proposal of a filter chaining mechanism see
>    org.owasp.util.filter (OCL) This framework is *NOT* intended only to
> filter out some patterns, but to mutate the filtered stuff.
>   For the filtering project I would propose *ONLY* to reject invalid
> input, since modification is a potential risk (the modification mechani=
sm
> could be abused)

I didn't include a "filter stack" in with the tarball, but we will have o=
ne.

> ((( (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
> ommitted. 9. Vector should be considered to be obsolete and not be used
> in favor of ArrayList (as well as Enumeration et al.)
>  )))

because I haven't coded any java in a year =3D )
All idiom problems are my own, sorry.

--=20
Alex Russell
al...@Se...
al...@ne...