cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <mhar...@hartle-klug.com>
Subject Re: [RT] Enhancing Cocoon Visibility
Date Wed, 16 Jan 2002 17:34:47 GMT
Stefano Mazzocchi wrote:

>Michael Hartle wrote:
>
>>Stefano Mazzocchi wrote:
>>
>>>Of course, we must prevent people from having the chance to disable this
>>>so we must make sure things have a very low impact on resource.
>>>
>>The first impression of mine is that approaching a viable interest like
>>this scares the shit out of me, pardon my language please.
>>
First of all, I overestimated the possibility of preventing "people from 
having the chance to disable this", so as long as the source is 
available, such a feature can be disabled in case anyone has the need 
for it; thanks to Peter Royal for reminding me.

>>* Being able to question version information to automatically exploit
>>defects or security holes is something that I started hating when I had
>>my first bigger source-level look into a project, which was the de-facto
>>standard DNS server BIND; a certain, specific DNS query (class=chaos,
>>type=txt) makes bind respond with more than sufficient versioning
>>information, a perfect basis for automation. I *do* believe in
>>publically declaring defects and security holes, but I am against making
>>it *that* easy for script kiddies.
>>
>You are suggesting 'security thru obscurity' then?
>
Given the common understanding of 'security thru obscurity', no, I am 
not suggesting that.

The motivation for adding a X-Cocoon-Version header is not a pure 
technical necessity; it for itself does not result in a better service 
or in technological improvements. It solely serves the purpose for 
remote, automated analysis from outside the entity that uses Cocoon. 
This may resulting into something good and useful like Netcraft or bad 
like quickly narrowing down available vulnerabilities, so I am in favour 
of making it switchable or at least notify users that it is there to 
make their own choice.

I would rather call it 'partial security thru transparency'; if an 
malicous attacker get no unnecessary hint where to begin, the difficulty 
of the task rises at least a magnitude.

>>* Not being able to turn of versioning information opens up a
>>possibility for articifical incompatibilities or product capabilities; I
>>do not yet expect this to happen, but I'd hate it to see some commercial
>>tool of mine either refuse to work with a cocoon-based web system or
>>request an upgrade to a pro version I directly could buy online.
>>
More than once I have experienced websites which deliver content 
depending on the browser solely for the purpose of telling me I 'd 
better switch browsers, although the website itself had no real 
dependency on IE or any other browser.

>what are you talking about? 
>
>Apache has such version information since day one but nothing prevented
>people to be happy and host securely with it.
>
For example, my favourite news page provides technical related news in 
german and is running

Server: Apache/1.3.12 (Unix) PHP/4.0.6 mod_oas/4.64 mod_fastcgi/2.2.4 
AuthMySQL/2.23

according to their headers; skimming through your favourite 
vulnerability database, you will rapidly find vulnerabilities for this 
Apache, e.g. http://xforce.iss.net/static/6921.php . These vulnerability 
databases are valuable tools to inform you as an *administrator* about 
potential defects in the software you are running, but as long as your 
systems kindly drop technological unnecessary fingerprints all around, 
they become a backbone to intrusion automation.

>>Concerning visibility, what about writing a book about Cocoon as a
>>community project, publishing it and using any what-so-ever-income to
>>help fund Apache ? What about writing articles for computer magazines
>>such as c't or iX in Germany ?
>>
>How do you know this isn't going on?
>
I am merely suggesting alternatives that I am considering as superior; 
if this is already going on, all the better ;)

Best regards,

Michael Hartle


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


Mime
View raw message