Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <48185739.3050104@inf.fu-berlin.de>
Date: Wed, 30 Apr 2008 13:25:45 +0200
From: Michael Osipov <ossipov@inf.fu-berlin.de>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Assuring Security by testing
References: <48184AEC.3010805@inf.fu-berlin.de> <481852C4.6030502@apache.org>
In-Reply-To: <481852C4.6030502@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mark Thomas wrote:
> Michael Osipov wrote:
>> Security advisories are taken up by a security team [3]. Does this team
>> or any other group/person take any measures to assure security with
>> testing tools,
>> with a special test plan or functional requirements?

Hello Mark,

I did not expect such a quick and long answer. Thanks first of all!

> We do occasionally receive reports to the security team that provide 
> outputs from various security testing tools. In short, the output is 
> nearly always complete garbage. For example, on one occasion a handful 
> of XSS issues were reported all of which were invalid whilst valid XSS 
> issues (later reported by others) were completely missed.

Were you reported the name of the tools with which the garbage out has 
been produced?

> I have yet to see an automated security test tool that offers any useful 
> output against the Tomcat code base.

I am investigating some tools too but their are still evolving.

> If you want to test a security audit tool then you can run it against an 
> old 4.1.x, 5.5.x or 6.0.x tag and see if it identifies any of the the 
> issues listed on the security pages.

Yes, that's probably what I can do but I am just a developer using 
tomcat as a servlet engine. I guess, due to tomcats complexity it'd take 
some time to understand how to run an attack at all.

> The majority of our security reports come:
> - from security researches who review, for whatever reason, parts of the 
> code they believe to be vulnerable to attack
> - users that discover a security issue through normal use
> 
> We also review every issue to see if there may be other places in the 
> codebase that are affected that the reporter did not mention. For 
> example we had a couple of XSS in the examples and when we looked at the 
> rest of the examples code we found a few more.
> 
> Every commit is reviewed by three committers before it is applied. 
> Security  is one of the considerations when reviewing a patch.
> 
> Getting off topic a little, where I think automated tools do have 
> something to offer is in the area of finding bugs. Checking for unused 
> variables etc often highlights (usually minor) bugs. Find bugs, PMD, 
> checkstyle, the stuff built in to Eclipse all have something to offer in 
> this area.

I am aware of all the tools you cited, but they don't do necessarily 
security testing (e.g. checkstyle). Did you ever come across LAPSE [1]?
I have investigated some tools, maybe they are in your interest to some 
extent. Check this article [2] on different tools, nikto [3], and Wfuzz [4].

Thanks again. I have to process you answers first before I proceed 
asking if you don't mind being asked.

Mike

[1] http://suif.stanford.edu/~livshits/work/lapse/
[2] 
http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/
[3] http://www.cirt.net/nikto2
[4] http://www.edge-security.com/wfuzz.php
-- 
<NO> OOXML - Say NO To Microsoft Office broken standard
http://www.noooxml.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org