RE: [Owasp-input-api-developers] Vision Document

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

> From: Christopher Todd <ch...@ch...>
> To: owa...@so...
> Subject: RE: [Owasp-input-api-developers] Vision Document
> Date: 12 Aug 2002 23:26:39 -0400
>
> If we are going to be voting Apache style (which I support), then I wou=
ld
> have vote -1 for this version of the doc for the following reasons (oth=
er
> than the specifics below, however, I think it is a good start):
>
> 1)  In Word format.  The document states that changes can be made by
> submitting diffs to the document.  How do you do that with a Word doc? =
 For
> consistency with the stated goal of the rest of the OWASP project, it
> should be in DocBook format (I volunteer to convert it - I'll try to do
> that this weekend).

the original document was a plain-text doc. Mark was kind enough to give =
it=20
some more formalized structure, which it was converted to a Word doc. As =
most=20
everyone knows, I'm as little of a MS word fan as the next guy, although =
I=20
find this not to be a legitimate objection. We're voting on the contents,=
 not=20
the formatting.

I'll convert it to docbook, keep everyone happy. blah.

> 2)  I strongly disagree with the statement:  "We will NOT develop for a=
ny
> proprietary technologies such as Microsoft .NET or Microsoft DCOM in an=
y
> shape or form."  Since when is Java *not* a proprietary technology?
> Furthermore, what you are saying with this statement is that MS coders
> don't deserve tools to help them make their web apps more secure, which=
 is
> preposterous.  They need tools like the Filters API even worse than fol=
ks
> who use Java.  To preclude any programming language would be irresponsi=
ble.

See my comments earlier in the day. Don't feel like re-typing it all. Bas=
ic=20
upshot of it is that I don't have a problem removing that language, but I=
'm=20
not going to vote in favor of specifying ASP/.NOT as a target platform fo=
r an=20
initial release.

> On the other hand, this is an open source software project, so if none =
of
> us feels like porting the API to .NET or whatever, then so be it.  :-)
>
> 3)  What is meant by "correctly 'Huffman Encoded' interfaces"?  This is=
n't
> an objection so much as a point of clarification -  maybe I'm a total
> ignoramus, but I usually assume that if I don't know what something mea=
ns,
> I'm probably not the only one.

I'll change it to read something along the lines of "easy to use and deve=
lop=20
with API naming conventions". The idea behind Huffman encoding is that if=
 you=20
sort based on the frequency of a substring, you can represent things in t=
heir=20
most efficient way. Basically, what I was trying to say is that things th=
at=20
get used all the time should have shorter names or shortcuts, and things =
that=20
are rarer should use more obvious (but longer) naming conventions.

> 4)  I am not sure I understand the whole boundary filter idea.  I don't
> necessarily want to re-hash something that's already been discussed, bu=
t if
> someone could provide a simple description or example, I'd appreciate i=
t.=20
> I know what boundary checking is, I'm just not sure you're talking abou=
t
> the same thing.

No, it's not the same thing.
The primary contention behind this Vision Doc is that very often we get=20
filtering wrong because we try to predict uses of data far in advance of =
it's=20
actual end-use. Instead of trying to filter at a single point in a system=
 and=20
then try to worry about every class of attack that might exist at various=
=20
stages in the processing of that data, we instead will define filters bas=
ed=20
on the inflow/outflow locations of data in the program, and will deal wit=
h=20
threats as they are present _at that boundary_. We won't try to block SQL=
=20
injection attacks in places other than just before we insert the data int=
o a=20
SQL statement, etc...
This model of filtering will give us a greater chance of getting it right=
 more=20
of the time, and will help to decrease the effect that environment drift =
will=20
place on the system, as assumptions made at a boundary won't be invalidat=
ed=20
simply because the data is now used in another context. Rather, we simply=
=20
filter for that new context before we output it there.

> 5)  I think we will need to consider a wider character set than UTF-8, =
for
> I18N reasons.  This may present a porting challenge, as different langu=
ages
> have differing levels of support for Unicode (just to cite one possible
> encoding).

I didn't suggest that we should use ONLY UTF-8, but rather that it was a =
sane=20
default. Rather, what I said is that all data MUST be reduced to a target=
=20
character set (of the developer's choice) before any filtering can begin,=
=20
otherwise we're just spitting in the wind.

> 6)  There are numerous typos and grammatical errors that I'll try to fi=
x
> when I convert this to DocBook this weekend.

I'll get it in docbook tomorrow, and then you can submit diff's to your h=
earts=20
content.

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