[Owasp-input-api-developers] SYN

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

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...