Menu
▾
▴
owasp-input-api-developers — Developers for OWASP Input API's
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
(26) |
May
|
Jun
(57) |
Jul
(22) |
Aug
(50) |
Sep
(14) |
Oct
(9) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tod H. <th...@ap...> - 2002-06-14 18:32:14
|
On Friday 14 June 2002 13:54, Gabriel Lawrence wrote: > On Fri, 2002-06-14 at 10:43, Mark Curphey wrote: > We can schedule a chat on Monday to go over this stuff and start to get > a consensus on the direction. Sound good? Not 100% sure I'll be in the office on Monday. Its 50/50 at this point. |
|
From: John P. <joh...@je...> - 2002-06-14 18:22:18
|
I think I would prefer to use IRC if possible. Feel free to log into irc.jelsoft.com if that is helpful, and we can meet there. Also, I'm in the UK, so please bear that in mind when planning times for Monday :-) I'll try and make it, but I can't promise anything! John > -----Original Message----- > From: owa...@li... > [mailto:owa...@li...]On Behalf > Of Gabriel Lawrence > Sent: 14 June 2002 18:54 > To: ma...@cu... > Cc: al...@se...; wi...@ce...; > th...@ap...; ve...@pa...; joh...@je...; > sj...@ju...; Input Mail List > Subject: Re: [Owasp-input-api-developers] Re: Filters Project > > > On Fri, 2002-06-14 at 10:43, Mark Curphey wrote: > > Looks perfect ! > > > > You know I hate AOL AIM as well but with the Linux and Trillian clients, > > webscarab team have been using it for weekly cats on Sunday. > > Yep... AIM has been working pretty well for me also. I've got Windows, > Solaris and Linux going with it so I'm kinda partial to it. (I tend to > use solaris as my primary desktop...) > > Why don't we all take an action item of reviewing whats been done so far > over the weekend and geling the ideas we have for what we want to do. If > possible please write up what you think the goals should be and thoughts > on where we are as Alex has already done. Then we can all read it and > think about the other folks thoughts/issues. > > We can schedule a chat on Monday to go over this stuff and start to get > a consensus on the direction. Sound good? > > Unless anyone has any real strong objections can we use AIM to? > > Offline please send me timing preferences for a chat. I'm not sure what > timezones everyone is in, and if folks object to work day meetings or > not. > > -gabe > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Owasp-input-api-developers mailing list > Owa...@li... > https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers > |
|
From: Tod H. <th...@ap...> - 2002-06-14 18:13:15
|
On Friday 14 June 2002 13:26, Gabriel Lawrence wrote: > On Thu, 2002-06-13 at 20:30, Mark Curphey wrote: > > Ideally this would be one of you so volunteers ? Gabe you volunteered > > for this once upon a time if I remember back that far. > > I'm up for giving it a shot. > > I'm assuming the first action items would be something along the lines > of: > > 1. Get mailing list issues sorted out. As I think this will be one of > the primary ways for us to keep in sync it needs to be done ASAP. Sounds good. I guess SourceForge has developer lists, we could use that? Dunno if it supports just a web interface or email... > > 2. Get some kind of minimal bio info from all the people working on the > project so we can know who we are... > > 3. Schedule a chat so we can get a feel for the goals of the project and > document them clearly. I have a jabber server available ;o). > > 4. Start farming out spec tasks to come up with what needs to be done to > meet the goals. > > Any other things I'm missing? Sounds good. > > -gabe |
|
From: Gabriel L. <ga...@bu...> - 2002-06-14 17:54:45
|
On Fri, 2002-06-14 at 10:43, Mark Curphey wrote: > Looks perfect ! > > You know I hate AOL AIM as well but with the Linux and Trillian clients, > webscarab team have been using it for weekly cats on Sunday. Yep... AIM has been working pretty well for me also. I've got Windows, Solaris and Linux going with it so I'm kinda partial to it. (I tend to use solaris as my primary desktop...) Why don't we all take an action item of reviewing whats been done so far over the weekend and geling the ideas we have for what we want to do. If possible please write up what you think the goals should be and thoughts on where we are as Alex has already done. Then we can all read it and think about the other folks thoughts/issues. We can schedule a chat on Monday to go over this stuff and start to get a consensus on the direction. Sound good? Unless anyone has any real strong objections can we use AIM to? Offline please send me timing preferences for a chat. I'm not sure what timezones everyone is in, and if folks object to work day meetings or not. -gabe |
|
From: Gabriel L. <ga...@bu...> - 2002-06-14 17:49:11
|
Howdy, Just thought I'd go through the quick process of introducing myself. I'm Gabriel Lawrence, I run a little security company called Butterfly Security. We have created software that wraps around a deployed web application and attempts to protect it from attacks. Imagine a cross between a firewall and an IDS focused soley on web applications. (<PLUG>We ship 1.0 of our product this week, come and buy a copy ;-) www.butterflysecurity.com</PLUG>) My interest in this project lies with the idea of giving web application developers better tools to make secure applications. From my experience at Butterfly and in the past developing secure web applications I've seen how difficult it is to make a good secure application - but also how many of the common mistakes are kind of simple stuff... Just so much to remember that people forget. In the past I've developed secure web applications for an ASP, I worked at Sun where I developed a web browser (it never saw the light of day, but I also contributed to the final release of HotJava) And I worked in their enterprise consulting organization developing java/web applications for companies such as CSX, BofA, Money Store, PeopleSoft, FedEx, Simon&Schuster and so on... I'm happy and comfortable working at any level from pure implementation, to technical leadership and project management. Because of my time constraints with Butterfly in this project I'm happy to take a more organizational role. -gabe |
|
From: Mark C. <mcu...@on...> - 2002-06-14 17:43:11
|
Looks perfect ! You know I hate AOL AIM as well but with the Linux and Trillian clients, webscarab team have been using it for weekly cats on Sunday. ---- Gabriel Lawrence <ga...@bu...> wrote: > On Thu, 2002-06-13 at 20:30, Mark Curphey wrote: > > > Ideally this would be one of you so volunteers ? Gabe you volunteered > > for this once upon a time if I remember back that far. > > I'm up for giving it a shot. > > I'm assuming the first action items would be something along the lines > of: > > 1. Get mailing list issues sorted out. As I think this will be one > of > the primary ways for us to keep in sync it needs to be done ASAP. > > 2. Get some kind of minimal bio info from all the people working on > the > project so we can know who we are... > > 3. Schedule a chat so we can get a feel for the goals of the project > and > document them clearly. > > 4. Start farming out spec tasks to come up with what needs to be done > to > meet the goals. > > Any other things I'm missing? > > -gabe > |
|
From: Gabriel L. <ga...@bu...> - 2002-06-14 17:27:07
|
On Thu, 2002-06-13 at 20:30, Mark Curphey wrote: > Ideally this would be one of you so volunteers ? Gabe you volunteered > for this once upon a time if I remember back that far. I'm up for giving it a shot. I'm assuming the first action items would be something along the lines of: 1. Get mailing list issues sorted out. As I think this will be one of the primary ways for us to keep in sync it needs to be done ASAP. 2. Get some kind of minimal bio info from all the people working on the project so we can know who we are... 3. Schedule a chat so we can get a feel for the goals of the project and document them clearly. 4. Start farming out spec tasks to come up with what needs to be done to meet the goals. Any other things I'm missing? -gabe |
|
From: Alex R. <al...@se...> - 2002-06-14 16:37:18
|
Hey all, Just wanted to quickly introduce myself (I'm sure Matt will do the same soon). I've just finished reading most of the archives for this list and I've had a look at the CVS checkins thus far. Since this project is fairly important (Matt and I were working on similar before we heard of OWASP), I've gotten permission from my employer to work on this "on the clock". I have a couple of thoughts right off the bat, and I expect them to be contentious, so please hear me out before flaming me into oblivion. 1.) IDMEF is more trouble than it's worth. IDS reporting integration might be a good thing (debatable for a first version), but IDMEF is absolutely the wrong way IMO to deal with that eventuality. The spec is vage, unimplementable (not that that's going to keep people from trying), and in reality doesn't buy us much. If we are hell-bent on doing IDS integration right off the bat, I suggest we look at SnortML's DTD, as it's significantly more sane. Better yet, let's just use syslog for the time being. It's there for a reason, it works, it can be network transparent, and it's used/understood by thousands of security professionals. 2.) filter categories. Developers aren't security people (by and large). Yes, they could figure out every corner case and come up with their own "filter" rules where they need them, but I think that if we put the onus on them to come up with match/reject classes, then we've done nothing more than give them a slower regexp engine. I honestly beleive we have a chance to enshrine best-practice filtering rules in code that people can just call based on what the "threat category" they are trying to avoid is. So, say someone is concerned about cross-site scripting and wants to store their data in a SQL database, we might provide a set of functions that they could composite like this (using python for example): def myFilter(str): str = OWASP_filter_xss(str) return OWASP_filter_db(str) obviously there might be some (optional) arguments to these functions that constrain their behaviour, but we should go for sane defaults and not provide more options than are strictly necessaray to safely strip out offending input. This can be thought of as a Huffman encoding problem to some extent: if we define an entire grammar that developers have to wrap their head around, then we're not lowering the bar any in providing secure input to their internal systems. Trickier things should have longer names, etc, but filtering on a basic set of threat classes should be made drop-dead simple. 3.) default behaviour. Reject everything by default, accept what matches. Doing things any other way says some very unflattering things about our understanding of what building secure software is all about. 4.) simplicity. Let's put togeather some _really useful_ filters right off the bat in the prototype language (whatever that might be) and start using/improving them. Once we've got some experience with what works and doesn't we can iterate and improve things as it fits. No need to engineer a solution to problems that might not even exist (except in our heads). -- Alex Russell al...@se... al...@ne... |
|
From: vertigo <ve...@pa...> - 2002-04-23 16:44:43
|
No problem. The Java version is almost done. I'll be committing it on Thursday probably. (It's on my laptop now.) I can do some of the Perl as well. Just tell me what classes you want to work on, and I can take the rest. I was trying to convince Cogent to take some of the load as well, but I have not heard rfom him. Be warned, my Perl is not very Perlish. If anything, I'm an anti-JAPH. I once wrote a long rant on the perlmonks(?) list in response to a message titled "Why I am a Perl programmer." The title of the response was "Why I am a Java programmer." ;) Nathan -----Original Message----- From: Steven J. Sobol [mailto:sj...@Ju...] Sent: Tuesday, April 23, 2002 12:14 PM To: vertigo Cc: owa...@so... Subject: Re: IDMEF is not an IDS On Tue, 16 Apr 2002, vertigo wrote: > The IDMEF is not an IDS. It is simply a messaging standard. BTW I'm going to try to get some work done on this before the 30th, at least I will read the draft... can't promise a ton of work, very busy. > Nathan > > -----Original Message----- > From: Steve Sobol [mailto:sj...@Ju...] > Sent: Tuesday, April 16, 2002 11:43 AM > To: vertigo > Subject: Re: [Owasp-input-api-developers] Code > > > At 10:59 AM 4/16/02 -0400, you wrote: > > >I've been working on an implementation of the IDWG's IDMEF > >(filters/doc/draft-ietf-idwg-idmef-xml-06.txt). It's been fairly > >easy-going in Java, and I imagine it should be even more simple in > >Perl. This is important for messaging, although it adds a bit of > >overhead. I need to see some implentations by the 30th. > > So we suddenly started creating an IDS system? > > I thought we were creating an input filter API. > > Are you sure this message was not meant for someone else? > > > > -- Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net "The Indians are unfolding into the 2002 season like a lethal lawn chair." (_News-Herald_ Indians Columnist Jim Ingraham, April 11, 2002) |
|
From: Steven J. S. <sj...@Ju...> - 2002-04-23 16:14:11
|
On Tue, 16 Apr 2002, vertigo wrote: > The IDMEF is not an IDS. It is simply a messaging standard. BTW I'm going to try to get some work done on this before the 30th, at least I will read the draft... can't promise a ton of work, very busy. > Nathan > > -----Original Message----- > From: Steve Sobol [mailto:sj...@Ju...] > Sent: Tuesday, April 16, 2002 11:43 AM > To: vertigo > Subject: Re: [Owasp-input-api-developers] Code > > > At 10:59 AM 4/16/02 -0400, you wrote: > > >I've been working on an implementation of the IDWG's IDMEF > >(filters/doc/draft-ietf-idwg-idmef-xml-06.txt). It's been fairly > >easy-going in Java, and I imagine it should be even more simple in > >Perl. This is important for messaging, although it adds a bit of > >overhead. I need to see some implentations by the 30th. > > So we suddenly started creating an IDS system? > > I thought we were creating an input filter API. > > Are you sure this message was not meant for someone else? > > > > -- Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net "The Indians are unfolding into the 2002 season like a lethal lawn chair." (_News-Herald_ Indians Columnist Jim Ingraham, April 11, 2002) |
|
From: vertigo <ve...@pa...> - 2002-04-16 18:52:49
|
Everyone,
All I want is an intelligent reporting mechanism. The IDMEF provides this.
From a design perspective, implementing this seperately makes sense. It
isolates reporting from filtering. Many moons ago I first saw the following
code and was amazed:
Systrace.setMinimumLevel("message");
Systrace.out("message", "Connecting to DB");
db.login("username", "password");
conn = db.connection();
if(conn == null) {
Systrace.out("error", "Connection Failed")
}
I was a pretty green programmer, and had all sorts of nasty debugging routines.
They were all replaced by this simple tool written by a co-worker. Having a
nice reporting tool is invaluable, especially when dealing with larger
applications. Moreoever, I believe that it will provide a modicum of validity
to the application. It says to the development community that we are serious
about standards--specifically with the emerging ones in this field.
The reason I would like to see this implemented separately is due to its the
overhead. The reporting mechanism should be optional, and used in cases where
people may not only want to scrub the input, but want to know what sort of
problems are being discovered.
Nathan
-----Original Message-----
From: owa...@li...
[mailto:owa...@li...]On Behalf
Of Christopher Todd
Sent: Tuesday, April 16, 2002 12:07 PM
To: owa...@so...
Subject: RE: [Owasp-input-api-developers] Code
Nathan,
By the way, I didn't mean to sound critical, I'm just a bit confused and
would like some clarification. After re-reading my post, I realized it had
a critical tone that was not intended. Sorry about that.
Regards,
Chris
-----Original Message-----
From: owa...@li...
[mailto:owa...@li...]On Behalf
Of Christopher Todd
Sent: Tuesday, April 16, 2002 11:27 AM
To: owa...@so...
Subject: RE: [Owasp-input-api-developers] Code
Nathan,
Ummm, I'm a bit lost...are you implementing simple APIs for scrubbing user
input, or creating some kind of IDS for webapps? Is there some design
documentation that I've missed? I've grabbed what's in CVS, and I've read
the website, and it's still not clear to me what you mean when you say "I
need some implementations by the 30th." Implementations of what?
Regards,
Chris
-----Original Message-----
From: owa...@li...
[mailto:owa...@li...]On Behalf Of
vertigo
Sent: Tuesday, April 16, 2002 10:59 AM
To: owa...@so...
Subject: [Owasp-input-api-developers] Code
Ok,
I've been working on an implementation of the IDWG's IDMEF
(filters/doc/draft-ietf-idwg-idmef-xml-06.txt). It's been fairly easy-going
in Java, and I imagine it should be even more simple in Perl. This is
important for messaging, although it adds a bit of overhead. I need to see
some implentations by the 30th. The major road-blocks I've encountered are
in the application-unique identifier area, and with NTP Timestamps. I'm
avoiding the latter issue, and I think we can do without proper timestamps
for now. The first issue, however is a little more important, and more
pervasive. We need to decide on a scheme for uniquely identifying attacks.
This will also be used in other areas of the application (signature IDs,
filter IDs, and basically any entity that may need to be uniquely
identified). It's pretty important.
I think we all know enough about this app to start writing some code. Start
with the IDMEF. This will lay the messaging groundwork, and allow us to
address nomenclature, vocabulary, blah blah blah. Once this is done, we can
move on to proper filtering. Todd is working on a DTD for our filter and
signature classes. Contact him for any updates. FYI, I'll be pretty busy
in the next couple of weeks. I have some new projects in the works (one
HUGE 4D to SQL Server migration and a couple of mini Perl CGIs). These ones
are paying my bills, so they get first priority of course. I believe
everyone has access to the CVS repository, but if not contact me. For those
who may not be familiar with CVS, remember it is not a replacement for
communication. For the next 2 weeks I'll be working in
'filters/lang/java/src/org/owasp/idmef' and 'filters/docs'.
Nathan
_______________________________________________
Owasp-input-api-developers mailing list
Owa...@li...
https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers
_______________________________________________
Owasp-input-api-developers mailing list
Owa...@li...
https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers
|
|
From: vertigo <ve...@pa...> - 2002-04-16 18:14:29
|
The IDMEF is not an IDS. It is simply a messaging standard. Nathan -----Original Message----- From: Steve Sobol [mailto:sj...@Ju...] Sent: Tuesday, April 16, 2002 11:43 AM To: vertigo Subject: Re: [Owasp-input-api-developers] Code At 10:59 AM 4/16/02 -0400, you wrote: >I've been working on an implementation of the IDWG's IDMEF >(filters/doc/draft-ietf-idwg-idmef-xml-06.txt). It's been fairly >easy-going in Java, and I imagine it should be even more simple in >Perl. This is important for messaging, although it adds a bit of >overhead. I need to see some implentations by the 30th. So we suddenly started creating an IDS system? I thought we were creating an input filter API. Are you sure this message was not meant for someone else? -- Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net "The Indians are unfolding into the 2002 season like a lethal lawn chair." (_News-Herald_ Indians Columnist Jim Ingraham, April 11, 2002) |
|
From: vertigo <ve...@pa...> - 2002-04-16 18:09:21
|
It's really quite simple. We don't have to use it, but the stuff I've written seems useful. Don't worry, we are not developing a full-on-robo IDS. This section is just a reporting tool--and yes, an implementation of the IDMEF. We will be scrubbing input, but when someone sends a "';DROP TABLE Users" string, I would sure like to know about it, wouldn't you? Nathan -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Christopher Todd Sent: Tuesday, April 16, 2002 11:27 AM To: owa...@so... Subject: RE: [Owasp-input-api-developers] Code Nathan, Ummm, I'm a bit lost...are you implementing simple APIs for scrubbing user input, or creating some kind of IDS for webapps? Is there some design documentation that I've missed? I've grabbed what's in CVS, and I've read the website, and it's still not clear to me what you mean when you say "I need some implementations by the 30th." Implementations of what? Regards, Chris -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of vertigo Sent: Tuesday, April 16, 2002 10:59 AM To: owa...@so... Subject: [Owasp-input-api-developers] Code Ok, I've been working on an implementation of the IDWG's IDMEF (filters/doc/draft-ietf-idwg-idmef-xml-06.txt). It's been fairly easy-going in Java, and I imagine it should be even more simple in Perl. This is important for messaging, although it adds a bit of overhead. I need to see some implentations by the 30th. The major road-blocks I've encountered are in the application-unique identifier area, and with NTP Timestamps. I'm avoiding the latter issue, and I think we can do without proper timestamps for now. The first issue, however is a little more important, and more pervasive. We need to decide on a scheme for uniquely identifying attacks. This will also be used in other areas of the application (signature IDs, filter IDs, and basically any entity that may need to be uniquely identified). It's pretty important. I think we all know enough about this app to start writing some code. Start with the IDMEF. This will lay the messaging groundwork, and allow us to address nomenclature, vocabulary, blah blah blah. Once this is done, we can move on to proper filtering. Todd is working on a DTD for our filter and signature classes. Contact him for any updates. FYI, I'll be pretty busy in the next couple of weeks. I have some new projects in the works (one HUGE 4D to SQL Server migration and a couple of mini Perl CGIs). These ones are paying my bills, so they get first priority of course. I believe everyone has access to the CVS repository, but if not contact me. For those who may not be familiar with CVS, remember it is not a replacement for communication. For the next 2 weeks I'll be working in 'filters/lang/java/src/org/owasp/idmef' and 'filters/docs'. Nathan _______________________________________________ Owasp-input-api-developers mailing list Owa...@li... https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers |
|
From: Christopher T. <ch...@ch...> - 2002-04-16 16:12:37
|
Nathan, By the way, I didn't mean to sound critical, I'm just a bit confused and would like some clarification. After re-reading my post, I realized it had a critical tone that was not intended. Sorry about that. Regards, Chris -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Christopher Todd Sent: Tuesday, April 16, 2002 11:27 AM To: owa...@so... Subject: RE: [Owasp-input-api-developers] Code Nathan, Ummm, I'm a bit lost...are you implementing simple APIs for scrubbing user input, or creating some kind of IDS for webapps? Is there some design documentation that I've missed? I've grabbed what's in CVS, and I've read the website, and it's still not clear to me what you mean when you say "I need some implementations by the 30th." Implementations of what? Regards, Chris -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of vertigo Sent: Tuesday, April 16, 2002 10:59 AM To: owa...@so... Subject: [Owasp-input-api-developers] Code Ok, I've been working on an implementation of the IDWG's IDMEF (filters/doc/draft-ietf-idwg-idmef-xml-06.txt). It's been fairly easy-going in Java, and I imagine it should be even more simple in Perl. This is important for messaging, although it adds a bit of overhead. I need to see some implentations by the 30th. The major road-blocks I've encountered are in the application-unique identifier area, and with NTP Timestamps. I'm avoiding the latter issue, and I think we can do without proper timestamps for now. The first issue, however is a little more important, and more pervasive. We need to decide on a scheme for uniquely identifying attacks. This will also be used in other areas of the application (signature IDs, filter IDs, and basically any entity that may need to be uniquely identified). It's pretty important. I think we all know enough about this app to start writing some code. Start with the IDMEF. This will lay the messaging groundwork, and allow us to address nomenclature, vocabulary, blah blah blah. Once this is done, we can move on to proper filtering. Todd is working on a DTD for our filter and signature classes. Contact him for any updates. FYI, I'll be pretty busy in the next couple of weeks. I have some new projects in the works (one HUGE 4D to SQL Server migration and a couple of mini Perl CGIs). These ones are paying my bills, so they get first priority of course. I believe everyone has access to the CVS repository, but if not contact me. For those who may not be familiar with CVS, remember it is not a replacement for communication. For the next 2 weeks I'll be working in 'filters/lang/java/src/org/owasp/idmef' and 'filters/docs'. Nathan _______________________________________________ Owasp-input-api-developers mailing list Owa...@li... https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers |
|
From: Christopher T. <ch...@ch...> - 2002-04-16 15:33:10
|
Nathan, Ummm, I'm a bit lost...are you implementing simple APIs for scrubbing user input, or creating some kind of IDS for webapps? Is there some design documentation that I've missed? I've grabbed what's in CVS, and I've read the website, and it's still not clear to me what you mean when you say "I need some implementations by the 30th." Implementations of what? Regards, Chris -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of vertigo Sent: Tuesday, April 16, 2002 10:59 AM To: owa...@so... Subject: [Owasp-input-api-developers] Code Ok, I've been working on an implementation of the IDWG's IDMEF (filters/doc/draft-ietf-idwg-idmef-xml-06.txt). It's been fairly easy-going in Java, and I imagine it should be even more simple in Perl. This is important for messaging, although it adds a bit of overhead. I need to see some implentations by the 30th. The major road-blocks I've encountered are in the application-unique identifier area, and with NTP Timestamps. I'm avoiding the latter issue, and I think we can do without proper timestamps for now. The first issue, however is a little more important, and more pervasive. We need to decide on a scheme for uniquely identifying attacks. This will also be used in other areas of the application (signature IDs, filter IDs, and basically any entity that may need to be uniquely identified). It's pretty important. I think we all know enough about this app to start writing some code. Start with the IDMEF. This will lay the messaging groundwork, and allow us to address nomenclature, vocabulary, blah blah blah. Once this is done, we can move on to proper filtering. Todd is working on a DTD for our filter and signature classes. Contact him for any updates. FYI, I'll be pretty busy in the next couple of weeks. I have some new projects in the works (one HUGE 4D to SQL Server migration and a couple of mini Perl CGIs). These ones are paying my bills, so they get first priority of course. I believe everyone has access to the CVS repository, but if not contact me. For those who may not be familiar with CVS, remember it is not a replacement for communication. For the next 2 weeks I'll be working in 'filters/lang/java/src/org/owasp/idmef' and 'filters/docs'. Nathan |
|
From: vertigo <ve...@pa...> - 2002-04-16 14:59:12
|
Ok, I've been working on an implementation of the IDWG's IDMEF (filters/doc/draft-ietf-idwg-idmef-xml-06.txt). It's been fairly easy-going in Java, and I imagine it should be even more simple in Perl. This is important for messaging, although it adds a bit of overhead. I need to see some implentations by the 30th. The major road-blocks I've encountered are in the application-unique identifier area, and with NTP Timestamps. I'm avoiding the latter issue, and I think we can do without proper timestamps for now. The first issue, however is a little more important, and more pervasive. We need to decide on a scheme for uniquely identifying attacks. This will also be used in other areas of the application (signature IDs, filter IDs, and basically any entity that may need to be uniquely identified). It's pretty important. I think we all know enough about this app to start writing some code. Start with the IDMEF. This will lay the messaging groundwork, and allow us to address nomenclature, vocabulary, blah blah blah. Once this is done, we can move on to proper filtering. Todd is working on a DTD for our filter and signature classes. Contact him for any updates. FYI, I'll be pretty busy in the next couple of weeks. I have some new projects in the works (one HUGE 4D to SQL Server migration and a couple of mini Perl CGIs). These ones are paying my bills, so they get first priority of course. I believe everyone has access to the CVS repository, but if not contact me. For those who may not be familiar with CVS, remember it is not a replacement for communication. For the next 2 weeks I'll be working in 'filters/lang/java/src/org/owasp/idmef' and 'filters/docs'. Nathan |
|
From: vertigo <ve...@pa...> - 2002-04-04 23:23:08
|
Wait, wait, wait. There still seems to be some misunderstanding of exactly when we start filtering. This is NOT a proxy server; it is an API. We start filtering AFTER the web-server has processed the request. The proxy idea would be fine, until we started working with SSL. The idea of an "SSL Terminator" was discussed on one of the mailing lists I'm on. This would be, in effect, a man-in-the-middle attack on the SSL protocol. It works, it's dead simple, but we're not doing that. Nathan -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Nik Cubrilovic Sent: Thursday, April 04, 2002 10:58 AM To: owa...@li... Subject: Re: [Owasp-input-api-developers] Re: goal and direction On Wed, 3 Apr 2002 Chr...@ey... wrote: > >Yes, web server plugins would be something more likely to fit into 'the > >big picture' at a later date, they would have to be written in C and be > >very specific to the target webserver (Apache1/Apache2/IIS). > > Perhaps I am confused about some implementation details. If we are going > to create Filters that sit in front of web applications, and which > intercept all HTTP requests before they ever reach the web app, how would > we do that if not in something like an Apache module or IIS ISAPI module? As a front end proxy even before the web server. ==> [proxy] ==> [webserver] ==> [application] there might obviously be SSL problems, and the webserver would see all request's coming in from the proxy (which would mess up ACL's). There is no reason why the 'proxy' cant be on the same machine as the webserver (webserver listening on localhost, proxy forwards requests). A model for the proxy might be (again, not much to do with filter's API, just discussion) as follows, request coming in from the top and passing through. [REQUEST] [FILTER USER INPUT] [BLOCK BAD INPUT] [LOG BAD INPUT/IDS] [CHECK SANITY OF HEADERS (NORMALISE)] [FORWARD REQUEST TO WEBSERVER] And then back from the webserver to the client [FILTER DB ERROR MESSAGES] - prevent 'information leakage' [FILTER UNEXPECTED SCRIPT (PAYLOADS)] I would not be suprised if there are existing implementations of this (cant recall any). Regards, -Nik _______________________________________________ Owasp-input-api-developers mailing list Owa...@li... https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers |
|
From: vertigo <ve...@pa...> - 2002-04-04 18:17:13
|
Everyone, As some poeple have noticed, I've been playing around in CVS repository. I was getting a little antsy and went ahead and wrote some code. Some of the additions in the repository are 0-length. I use many of these as mental notes, and some may be deleted in the future. They help me grok the physical design of the app, predict any maintenance headaches that might come our way, and allow me to write makefiles that I use heavily during development. The ASP, Perl, and PHP directories are simply place-holders for now. I've begun implementing the Intrusion Detection Working Group's Intrusion Detection Message Exchange Format in Java. I believe this draft standard to be a good place to start from an architecture and reporting perspective. The most recent version of the document can be found in filters/docs/ as draft-ietf-idwg-idmef-xml-06.txt. The code is located in filters/lang/java/src/org/owasp/idmef. Nathan |
|
From: vertigo <ve...@pa...> - 2002-04-04 17:46:35
|
A plugin would be a more reliable solution to the problem of detecting web-app attacks. As was discussed earlier, without access to the request at the socket-level, we are at a disadvantage. The project as it stands, however, is intended to be a set of APIs. A plugin can be a long-term goal, or perhaps a spinoff project. Nathan -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Steven J. Sobol Sent: Wednesday, April 03, 2002 10:35 AM To: Chr...@ey... Cc: owa...@li... Subject: Re: Doh! I screwed up WAS:Re: [Owasp-input-api-developers] Status? On Wed, 3 Apr 2002 Chr...@ey... wrote: > However, when I first heard the description of this project, I imagined > that the product would be a set of APIs That's what I figured, myself. > I was wondering if you all thought there is room in this project for, in > essence, two products - a web/app server plugin, and a programming API? Of > course, the web server plugins themselves can and probably will use the > input-scrubbing API, so it's not like the two products will be completely > disassociated. I think this might be a good idea. Of course, I don't really have the expertise to do the server modules. I can work on the APIs for several scripting languages. -- Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net Need a programmer? Resume going up at http://sourceforge.net/users/webdude216 _______________________________________________ Owasp-input-api-developers mailing list Owa...@li... https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers |
|
From: Nik C. <ni...@ni...> - 2002-04-04 15:58:07
|
On Wed, 3 Apr 2002 Chr...@ey... wrote: > Nik, > > >But, a large portion of web application developers are oblivious to the > >risks that web applications pose. > <snip/> > >This obviously leaves a large 'market' for server (ie. pre > >web-application) filtering and intrusion detection, which is where i see > a > >small split within this project and two trajectories. > > > >1. Filtering API's for developers > >2. Webserver/scripting engine patches or modules for webmaster's and > >server administrators. > > Right. The point I was making is that both approaches are reasonable; I > merely wanted to prod the list into discussing which approach this project > should take, or whether both approaches should be pursued. My opinion would be to focus on the API for developers first, since it is easier to implement and the main aim of the project. Am i right in saying that the API will be targetting ASP/PHP/Perl/Java? > I think that would be an excellent starting point, using the ASAC material > (and other suitable materials) as a guide. Want to start by pasting some references? I am not sure how many people we have on this list at the moment (ie. are all developers here) and if Nathan wants to get the ball rolling. > >Yes, web server plugins would be something more likely to fit into 'the > >big picture' at a later date, they would have to be written in C and be > >very specific to the target webserver (Apache1/Apache2/IIS). > > Perhaps I am confused about some implementation details. If we are going > to create Filters that sit in front of web applications, and which > intercept all HTTP requests before they ever reach the web app, how would > we do that if not in something like an Apache module or IIS ISAPI module? As a front end proxy even before the web server. ==> [proxy] ==> [webserver] ==> [application] there might obviously be SSL problems, and the webserver would see all request's coming in from the proxy (which would mess up ACL's). There is no reason why the 'proxy' cant be on the same machine as the webserver (webserver listening on localhost, proxy forwards requests). A model for the proxy might be (again, not much to do with filter's API, just discussion) as follows, request coming in from the top and passing through. [REQUEST] [FILTER USER INPUT] [BLOCK BAD INPUT] [LOG BAD INPUT/IDS] [CHECK SANITY OF HEADERS (NORMALISE)] [FORWARD REQUEST TO WEBSERVER] And then back from the webserver to the client [FILTER DB ERROR MESSAGES] - prevent 'information leakage' [FILTER UNEXPECTED SCRIPT (PAYLOADS)] I would not be suprised if there are existing implementations of this (cant recall any). Regards, -Nik |
|
From: <Chr...@ey...> - 2002-04-03 19:17:13
|
Nik,
>But, a large portion of web application developers are oblivious to the
>risks that web applications pose.
<snip/>
>This obviously leaves a large 'market' for server (ie. pre
>web-application) filtering and intrusion detection, which is where i see
a
>small split within this project and two trajectories.
>
>1. Filtering API's for developers
>2. Webserver/scripting engine patches or modules for webmaster's and
>server administrators.
Right. The point I was making is that both approaches are reasonable; I
merely wanted to prod the list into discussing which approach this project
should take, or whether both approaches should be pursued.
>yes, this would be simple to implement across PHP, ASP, Perl and Java.
>Should we start developing a function framework and specification for
>each of functions?
>Perhaps a good starting point would be to firstly identify all threats
>(cross site scripting, SQL injection), and then come up with relative
>functions to sanatize. This will still not solve a lot of common problems
>in web applications..
I think that would be an excellent starting point, using the ASAC material
(and other suitable materials) as a guide.
>An ideal option would be for the developer to explicitly allow certain
>variables to a page, and all other user passed variables to be cropped
>out/ignored by the web application (hard to implement in php, easy in
>ASP), and then the variables that have been explicitly allowed to
progress
>into the web application, for the filters to be applied.
A good idea, and also fairly easy to implement in servlets (particularly
in the 2.3 spec - the javax.servlet.Filter class is designed to do exactly
that sort of thing).
This approach could also be implemented in the webserver plugin approach,
where a sysadmin defines the HTTP headers and form fields that will be
accepted for a given resource (that is, a servlet/JSP/PHP/Perl
script/page). I have seen webapps where the developer simply loops
through all the form fields in the HTTP request, and prints them to the
page. The developer may only be expecting the fields "name" and
"address", but then a hacker can easily construct a POST request that also
includes something sneaky like "password=Runtime.exec("cat /etc/passwd")".
<snip/>
>Yes, web server plugins would be something more likely to fit into 'the
>big picture' at a later date, they would have to be written in C and be
>very specific to the target webserver (Apache1/Apache2/IIS).
Perhaps I am confused about some implementation details. If we are going
to create Filters that sit in front of web applications, and which
intercept all HTTP requests before they ever reach the web app, how would
we do that if not in something like an Apache module or IIS ISAPI module?
Furthermore, if we create plugins for Apache and IIS, we have just nailed
87.56% of the web server market (according to the most recent Netcraft
survey). That's pretty good coverage.
I'm not being dogmatic about any of this...the Input Filters API project
will be a valuable contribution to the community whether it produces an
API, a set of webserver plugins, or both.
Sincerest regards,
Chris Todd
Ernst & Young LLP
Security and Technology Solutions (STS)
chr...@ey...The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Ernst & Young LLP
|
|
From: Nik C. <ni...@ni...> - 2002-04-03 17:29:03
|
On Tue, 2 Apr 2002, Christopher Todd wrote: > Well, I guess that would be a reasonable question for debate. Are we trying > to help people write more secure web applications, or are we trying to help > make web applications more secure? Hi Chris, In terms of 'helping people write more secure web applications', I think that is the main aim of OWASP, and the filters project is one part of the overall goal. But, a large portion of web application developers are oblivious to the risks that web applications pose. While it is hoped that OWASP will raise awarness in the field, it still leaves a lot of potentially insecure sites out there, with lazy (or unknowing) developers unwilling to implement a filtering API (besides, there are already simple methods native to each language to test/sanatize user input). Developers are often under time constraints, or have many other reasons to overlook security whilst developing a web application (pick up a book on web app development and note how much of it is devoted to security issues). This obviously leaves a large 'market' for server (ie. pre web-application) filtering and intrusion detection, which is where i see a small split within this project and two trajectories. 1. Filtering API's for developers 2. Webserver/scripting engine patches or modules for webmaster's and server administrators. Combined, they are obviously a powerful combination (combined with application level intrusion detection that could be integrated within a webserver filtering tool). Developers can take responsobility for implementing the filtering API, and/or server administrator(s) can take responsability for web server based filtering (these roles can often be split widely, ie. in an outsorcing situation). > > For the purposes of the Input Filters API project, it seems obvious that > implementing an API for each language will be the easiest and quickest way > to produce something useful to the community, so long as we can agree on an > interface that will be common across all the languages (or at least as > common as the syntaxes of the languages will allow). For example, once > we've decided that the methods > > public String removeParentheses(String input) > public String removeSemicolons(String input) > public String sanitizeInput(String input, Regex exclusionPattern) > > (to put up a few hypothetical examples in Java syntax) are methods we need > in the API, then it is up to the individual language implementors to figure > out how to implement them. That can be done pretty quickly. > yes, this would be simple to implement across PHP, ASP, Perl and Java. Should we start developing a function framework and specification for each of functions? Perhaps a good starting point would be to firstly identify all threats (cross site scripting, SQL injection), and then come up with relative functions to sanatize. This will still not solve a lot of common problems in web applications.. how many times have you seen something like: http://www.server.com/store/account_info.php?id=12 then being able to increment id to pick up somebody else's account? I guess this is outside of the scope of this project. There are also other vulnerabilities such as script?include=/etc/passwd trickiness (see: http://www.securereality.com.au/studyinscarlet.txt) that can not be easily solved, since if the developer has not accounted for the possibility of that variable being passed to the script, then how can they defend against it? An ideal option would be for the developer to explicitly allow certain variables to a page, and all other user passed variables to be cropped out/ignored by the web application (hard to implement in php, easy in ASP), and then the variables that have been explicitly allowed to progress into the web application, for the filters to be applied. perhaps i am getting ahead of myself. > Implementing web server plugins obviously is a much more complicated task. > <snip> > So to summarize, basically I agree with you, but in the long term, I think > we should at least consider the potential usefulness of creating web server > plugins. > Yes, web server plugins would be something more likely to fit into 'the big picture' at a later date, they would have to be written in C and be very specific to the target webserver (Apache1/Apache2/IIS). enough ranting :) Nik Cubrilovic www.nik.com.au |
|
From: <Chr...@ey...> - 2002-04-03 15:55:17
|
Steve,
Yeah, I'm not a C coder, so writing an Apache/ISAPI/NSAPI plugin or module
is beyond my skill. I think I could implement a Servlet container version
of the plugin, though. And I would certainly be willing to work on the
Java APIs. I've done some PERL, PHP, and VBScript, and I'm quite
comfortable with Regular Expressions, so I could make some contribution
there, though I hesitate to volunteer for those languages because it's
been a while since I used them, and I was never a guru with them anyway.
Plus, I'm awaiting permission from my employer to make contributions
(confidentiality and intellectual property issues).
Sincerest Regards,
Chris Todd
Ernst & Young LLP
Security and Technology Solutions (STS)
chr...@ey...
"Steven J. Sobol" <sj...@Ju...>
04/03/2002 10:35 AM
To: Chr...@ey...
cc: owa...@li...
Subject: Re: Doh! I screwed up WAS:Re: [Owasp-input-api-developers] Status?
On Wed, 3 Apr 2002 Chr...@ey... wrote:
> However, when I first heard the description of this project, I imagined
> that the product would be a set of APIs
That's what I figured, myself.
> I was wondering if you all thought there is room in this project for, in
> essence, two products - a web/app server plugin, and a programming API?
Of
> course, the web server plugins themselves can and probably will use the
> input-scrubbing API, so it's not like the two products will be
completely
> disassociated.
I think this might be a good idea. Of course, I don't really have the
expertise to do the server modules. I can work on the APIs for several
scripting languages.
--
Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek)
JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net
Need a programmer? Resume going up at http://sourceforge.net/users/webdude216
The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Ernst & Young LLP
|
|
From: Steven J. S. <sj...@Ju...> - 2002-04-03 15:35:29
|
On Wed, 3 Apr 2002 Chr...@ey... wrote: > However, when I first heard the description of this project, I imagined > that the product would be a set of APIs That's what I figured, myself. > I was wondering if you all thought there is room in this project for, in > essence, two products - a web/app server plugin, and a programming API? Of > course, the web server plugins themselves can and probably will use the > input-scrubbing API, so it's not like the two products will be completely > disassociated. I think this might be a good idea. Of course, I don't really have the expertise to do the server modules. I can work on the APIs for several scripting languages. -- Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net Need a programmer? Resume going up at http://sourceforge.net/users/webdude216 |
|
From: <Chr...@ey...> - 2002-04-03 14:25:19
|
Sorry everyone, but it would appear that I sent the email below to owa...@li... instead of the main list. Sorry for any confusion that may have caused. Sincerest Regards, Chris Todd Ernst & Young LLP Security and Technology Solutions (STS) chr...@ey... May I assume from the description of this project on the webpage, and from this thread, that the goal of the project is to provide, in essence, web server plugins that filter data before they ever hit the web applications? That's a pretty cool idea, I have to admit. However, when I first heard the description of this project, I imagined that the product would be a set of APIs that developers could use in their applications to scrub user input. Essentially, method or function calls that would take a String of user input, and return the sanitized String. (This is radically simplified, of course, but I think you get the idea) The distinction between these approaches, to borrow a phrase from J2EE, is that the former is "Declarative Security", whereas the latter is "Programmatic Security". Obviously, there is a place for both approaches in the world of web application security, and each approach has its advantages and disadvantages. For example, many large corporations are not going to want to modify their production webservers, particularly given the problems with CodeRed et al. Conversely, in organizations that have security-knowledge systems administrators (not too uncommon), but security-ignorant web developers (unfortunately, way too common), the web server plugin is an excellent solution. I was wondering if you all thought there is room in this project for, in essence, two products - a web/app server plugin, and a programming API? Of course, the web server plugins themselves can and probably will use the input-scrubbing API, so it's not like the two products will be completely disassociated. Regards, Chris Todd Ernst & Young LLP Security and Technology Solutions (STS) chr...@ey... |
1 message has been excluded from this view by a project administrator.
