From: Matthew W. <wi...@ce...> - 2002-08-12 23:48:40
|
On Mon, 12 Aug 2002 17:02:56 -0500 (CDT) Alex Russell <al...@se...> wrote: > On Mon, 12 Aug 2002, John Percival wrote: > > > Hi guys, > > > > I just had a read through, and that doc looks clear and informative. The > > only thing that I would question, without wanting to open a can of worms, is > > the choice not to develop for DCOM/.NET technology. I am not in a position > > to create such filters, but is it our position to judge what language our > > 'customers' will be using? > > No, and perhaps doing a VBScript/D-flat verion is worth considering. > That said, developers using MS tech are starting from an inherently > disadvantaged position WRT to security (IIS, MSSQL, etc..), and probably > have bigger problems. > > I think we can safely say that we won't refuse a contributed MS-tech > version of the filters once we have them working in a reference > language, but I for one won't be spending much (any?) time on that port > as I simply don't have any MS software to develop against. Perhaps when > Mono goes gold... Completely agreed. If there is a developer who wants to contribute a VBD/Db I say more power to them, but I can't see myself spending any appreciable amount of time developing on/for this platform. (Hey, I had to play with ISS's Internet Scanner and almost went out of my mind -- go Nessus!) In the end, I suppose its not fair to rule out these languages based on their vendor or said vendor's intentions, but as Alex said, anyone developing for this platform using these tools probably has more to worry about. (Though the latest OpenSSL escapade doesn't say much for us, other than turn-around time on patches.. :->) > > Additionally, providing filters for MS languages, while undeniably > necessaray, almost condones their use for security-critical applications, > and I think that if we ever do ship such a port, we should point out to > developers the insecure posture that relying upon a vendor like MS > inherently creates. I wish I would have read this paragraph before writing all of that up there :-) > > Should we grease the squeaky wheel? I don't have a strong opinion one way > or the other, save that for the time being I'm "out" when it comes to > developing such a port. > This document, though, is most definitely on the write track (save the fact that its not in PDF or PS, but rather MSWord -- Thanks OpenOffice!). In short, I've a "Yes" vote. -matt |
From: Christopher T. <ch...@ch...> - 2002-08-13 03:08:19
|
If we're going to use the Apache system of voting, then a reasonable question to ask would be "Who gets to vote?", or more accurately, who gets veto rights. And for those of you not familiar with the Apache system, -1's need to be justified with arguments as to why the proposal/code/patch/whatever is insufficient. Regards, Chris -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Mark Curphey Sent: Monday, August 12, 2002 6:21 PM To: John Percival; Alex Russell; owa...@so... Cc: Mark Curphey Subject: RE: [Owasp-input-api-developers] Vision Document Good deal. Looks like the first vote for yes. What I was talking to Gabe and Alex about is using the doc as THE vision for the project and everyone having a vote before the end of this biz week (5pm Friday Pacific Time) so we can move on and get a release done. The OWASP portal is being built using UPortal so we need this ;-) It seems to (me anyway) make sense that if there are things you think are missing or its not what you think we should be doing, then please append the issue as a voting item and send them out to Gabe before Wednesday. Gabe can send out a list of all the items people feel need to be voted on on Thursday and we can tally votes by Friday night. I suggest we use the Apache system or a +1, 0 or -1 for each item and add the total. If you don't vote it don't count so be warned. Mine is for +1 on the vision document as it stands with no alterations. I think it sums up what the project is trying to do and needs to do, even if it is somewhat off from what has been done to date. Cheers ---- John Percival <joh...@je...> wrote: > Hi guys, > > I just had a read through, and that doc looks clear and informative. The > only thing that I would question, without wanting to open a can of worms, is > the choice not to develop for DCOM/.NET technology. I am not in a position > to create such filters, but is it our position to judge what language our > 'customers' will be using? > > On the whole though, good work! > > John > > > -----Original Message----- > > From: owasp-input-api-developers- ad...@li... > > [mailto:owasp-input-api-developers- ad...@li...]On Behalf > > Of Alex Russell > > Sent: 12 August 2002 18:06 > > To: owa...@so... > > Cc: Mark Curphey > > Subject: [Owasp-input-api-developers] Vision Document > > > > > > Hey Everyone, > > > > After much discussion, the project is now (apparently) stalled. To > > combat this, Mark Curphey and I have drafted a "vision document" to > > outline the purpose of the project and our preferred approach to > > development. > > > > You'll find the document attached for your review. Gabe or Mark should > > be announcing a vote on the document soon, so it'd be good if everyone > > were familiar with it's contents before we vote to adopt it. > > > > Thanks, > > > > Alex > > > > -- > > Alex Russell > > al...@Se... > > al...@ne... > > > > > ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ Owasp-input-api-developers mailing list Owa...@li... https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers |
From: Christopher T. <ch...@ch...> - 2002-08-13 03:36:02
|
If we are going to be voting Apache style (which I support), then I would have vote -1 for this version of the doc for the following reasons (other 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). 2) I strongly disagree with the statement: "We will NOT develop for any proprietary technologies such as Microsoft .NET or Microsoft DCOM in any 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 folks who use Java. To preclude any programming language would be irresponsible. 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 isn't an objection so much as a point of clarification - maybe I'm a total ignoramus, but I ususally assume that if I don't know what something means, I'm probably not the only one. 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, but if someone could provide a simple description or example, I'd appreciate it. I know what boundary checking is, I'm just not sure you're talking about the same thing. 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 languages have differing levels of support for Unicode (just to cite one possible encoding). 6) There are numerous typos and grammatical errors that I'll try to fix when I convert this to DocBook this weekend. Regards, Chris -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Alex Russell Sent: Monday, August 12, 2002 1:06 PM To: owa...@so... Cc: Mark Curphey Subject: [Owasp-input-api-developers] Vision Document Hey Everyone, After much discussion, the project is now (apparently) stalled. To combat this, Mark Curphey and I have drafted a "vision document" to outline the purpose of the project and our preferred approach to development. You'll find the document attached for your review. Gabe or Mark should be announcing a vote on the document soon, so it'd be good if everyone were familiar with it's contents before we vote to adopt it. Thanks, Alex -- Alex Russell al...@Se... al...@ne... |
From: Matt W. <wi...@ce...> - 2002-08-13 04:03:18
|
On Mon, 2002-08-12 at 22:26, Christopher Todd wrote: [...] > 3) What is meant by "correctly 'Huffman Encoded' interfaces"? This isn't > an objection so much as a point of clarification - maybe I'm a total > ignoramus, but I ususally assume that if I don't know what something means, > I'm probably not the only one. While I know what Huffman Encoding is, wrt text compression, I too fail to understand what "correctly 'Huffman Encoded' interfaces" really means. > > 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, but if > someone could provide a simple description or example, I'd appreciate it. I > know what boundary checking is, I'm just not sure you're talking about the > same thing. The boundary idea is pretty simple. Its basically deciding when you need to filter the data. For example, filtering SQL injection is something you would want to do on input, when the user sends there data. However, filtering XSS might be something you wish to do when displaying said data. > > 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 languages > have differing levels of support for Unicode (just to cite one possible > encoding). Bah. > > 6) There are numerous typos and grammatical errors that I'll try to fix > when I convert this to DocBook this weekend. Here we go again :> -matt -- Matthew Wirges Developer, CERIAS Incident Response Database wi...@ce... |
From: Alex R. <al...@ne...> - 2002-08-13 06:41:03
|
> 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... |