Re: [Owasp-input-api-developers] filters/java

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

On Wednesday 30 October 2002 03:28, Ingo Struck wrote:
> Hi...
>
> > have a look through the archives and try to find the "vision document=
".
>
> Hm... I couldnt locate it. :o(

see attached DocBook document.

> But I saw the idmef thing together with some other code...
> What`s that? For me it seems to be a different way to describe
> vulnerabilities, so is it a second VulnXML draft?
> Please tell me some words about status/purpose.

this is water under the bridge. Please read the archives for details.

> > canonicalization.=20
>
> Wew, I think this is really a tricky / huge problem.
> As you surely know, nearly all charset de/encoding mechanisms are not
> trivial. If you really try to canonicalize everything before filtering,=
 I
> bet that the only attack an attacker has to try out is a simple
> overloading.

that's why we force a charset. All Unicode compliant converters will use=20
"shortest encoding" semantics, and so we shouldn't have to worry about=20
this.

> As I already stated, on the protocol / db layer (which should considere=
d
> to be the most sensitive one) you can assume at least everything to be
> eight-bit, if not seven (ascii) or even six bit (base64).
> Thus, the simple canonicalization on that layer would consist of bit
> masking.
>
> The filters on other stages may well need a full-fledged charset
> canonicalization, but it should only happen comparitively seldom that a
> user has to provide charset-dependent input (e.g. i18n names / search
> patterns or the like).

we'll worry about efficiency once we have correctness. Premature=20
optimization is the root of all evil.


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