owasp-input-api-developers

[Owasp-input-api-developers] Testing tool/framework and development platform survey

[Christopher T. <ch...@ch...>]

Hello all,

I've been working on an automated tool for unit testing the Filters API.
The purpose of the tool is to validate that the API functions/methods
perform as expected.  Before I put much more effort into it, though, I
wanted to ask the group a few questions.

1)  Will this be helpful and/or valuable?

2)  I was planning on building the tool around Ant, a Java/XML based build
tool, and HTTPUnit, a web application unit testing tool.  You won't need to
know Java to construct test cases, just a little XML.  But for those of you
developing the ASP, Perl or PHP ports of the API, would you be annoyed about
having to install Java and Ant on your development boxes?

3)  I was planning on having the tool create .jsp, .asp., .php, etc. files
that take the specified input and run it through the Filter API
functions/methods, but this requires deploying those pages in a working web
server environment.  May I safely assume that everyone working on the
various languages will have access to such a setup?

And finally, just out of curiosity, what development platforms is everyone
using?  I use Emacs on Linux, Win98 and Win2k.  I have access to Apache
(w/Perl & PHP) on Linux, Tomcat on any platform, and IIS 5.

Chris

Re: [Owasp-input-api-developers] Testing tool/framework and development platform survey

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

On Sun, 18 Aug 2002, Christopher Todd wrote:

> Hello all,
> 
> I've been working on an automated tool for unit testing the Filters API.
> The purpose of the tool is to validate that the API functions/methods
> perform as expected.  Before I put much more effort into it, though, I
> wanted to ask the group a few questions.
> 
> 1)  Will this be helpful and/or valuable?

Yes. Incredibly so.
 
> 2)  I was planning on building the tool around Ant, a Java/XML based build
> tool, and HTTPUnit, a web application unit testing tool.  You won't need to
> know Java to construct test cases, just a little XML.  But for those of you
> developing the ASP, Perl or PHP ports of the API, would you be annoyed about
> having to install Java and Ant on your development boxes?

I think that any test environment is going to necessarialy be slightly
complex (involved a web server, correctly configured languages, etc...),
so I don't (personally) feel that Java/Ant is a problem. If anyone is
dead set against it, speak up now = )

> 3)  I was planning on having the tool create .jsp, .asp., .php, etc. files
> that take the specified input and run it through the Filter API
> functions/methods, but this requires deploying those pages in a working web
> server environment.  May I safely assume that everyone working on the
> various languages will have access to such a setup?

Probably not. I think it'll be a better bet to find one environment
against which we can test most of these languages and then spit back
reports about what succeeded and what failed. Not sure there's a need
for each of us to configure servers to support all (or even most) of
these languages. It can only get more complex when we introduce DBs into
the mix, so for the time being I'm going to advocate a central testing
setup of some sort. Not sure how we'll make it a reality (suggestions
welcome), but it seems a good way to start.

> And finally, just out of curiosity, what development platforms is everyone
> using?  I use Emacs on Linux, Win98 and Win2k.  I have access to Apache
> (w/Perl & PHP) on Linux, Tomcat on any platform, and IIS 5.

I've got access to Apache on Linux and OpenBSD supporting  Python, PHP, 
Tomcat/JSP, and Perl.

For editing I use vim with 8-space tabs, and tabs-as-tabs (no auto-space
insertion).

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

Re: [Owasp-input-api-developers] Testing tool/framework and development platform survey

[Matt W. <wi...@ce...>]

On Sun, 2002-08-18 at 16:54, Alex Russell wrote:
> On Sun, 18 Aug 2002, Christopher Todd wrote:
> 
> > Hello all,
> > 
> > I've been working on an automated tool for unit testing the Filters API.
> > The purpose of the tool is to validate that the API functions/methods
> > perform as expected.  Before I put much more effort into it, though, I
> > wanted to ask the group a few questions.
> > 
> > 1)  Will this be helpful and/or valuable?
> 
> Yes. Incredibly so.

Yes, yes, yes.  Tests are a good idea in any project, this one is no
exception.  The problem will be coming up with enough different cases to
cover as many methods of "attack" as possible.  

>  
> > 2)  I was planning on building the tool around Ant, a Java/XML based build
> > tool, and HTTPUnit, a web application unit testing tool.  You won't need to
> > know Java to construct test cases, just a little XML.  But for those of you
> > developing the ASP, Perl or PHP ports of the API, would you be annoyed about
> > having to install Java and Ant on your development boxes?
> 
> I think that any test environment is going to necessarialy be slightly 
> complex (involved a web server, correctly configured languages, etc...),
> so I don't (personally) feel that Java/Ant is a problem. If anyone is
> dead set against it, speak up now = )
I don't see why a web server is necessary to test these cases?  Our
filters are for filtering input.  While OWASP is geared towards web
applications, I don't see why someone couldn't use these filters in
other applications.  

We could write a test suite application in an appropriate language (I'm
thinking perl) that could invoke a simple application written in each
language that filters test data by a supplied filter, this simple app
then returns the filtered data to the test suite application which
determines if the output is correct.  This can be easily run after each
build.

As far as Java/Ant is concerned, I don't know.  I've never used it
myself, but I am willing to learn.  I really don't see this being a big
problem with the scripting languages since nothing special should need
to be done on a build.
> 
> > 3)  I was planning on having the tool create .jsp, .asp., .php, etc. files
> > that take the specified input and run it through the Filter API
> > functions/methods, but this requires deploying those pages in a working web
> > server environment.  May I safely assume that everyone working on the
> > various languages will have access to such a setup?

> 
> Probably not. I think it'll be a better bet to find one environment
> against which we can test most of these languages and then spit back
> reports about what succeeded and what failed. Not sure there's a need
> for each of us to configure servers to support all (or even most) of
> these languages. It can only get more complex when we introduce DBs into
> the mix, so for the time being I'm going to advocate a central testing
> setup of some sort. Not sure how we'll make it a reality (suggestions
> welcome), but it seems a good way to start.

./testSuite --lang=java -f tests/xssTests.xml ? 

The test suite application doesn't have to run everything, only what we
tell it so people who aren't developing on other languages don't need to
install anything extra, other than the languages they are using and of
course the language that the test suite is written (which is why perl
would probably be best, its available on most major unix distributions
and I hear ActiveState Java is pretty decent).  Besides, I would think
that we would want to package up the tools for each language for
individual distribution.  ( I don't need the java filters for my php
applications).
> 
> > And finally, just out of curiosity, what development platforms is everyone
> > using?  I use Emacs on Linux, Win98 and Win2k.  I have access to Apache
> > (w/Perl & PHP) on Linux, Tomcat on any platform, and IIS 5.
> 
> I've got access to Apache on Linux and OpenBSD supporting  Python, PHP, 
> Tomcat/JSP, and Perl.
> 
> For editing I use vim with 8-space tabs, and tabs-as-tabs (no auto-space
> insertion).

I develop on Linux, using vim.  I have Apache with perl/mod_perl, php,
python, mod_python, yadda, yadda, yadda..  I can install anything else I
need.

AND DAMMIT.  I just realized that my test application idea breaks down
when we throw ASP into the mix. 
(/me mumbles something dirty about Microsoft)


-matt

-- 
Matthew Wirges
Developer, CERIAS Incident Response Database
wi...@ce...
Credo quia absurdum est.