[OWASP-TESTING] Checking in
Stuttard, Dafydd N (UK - London)
dstuttard at deloitte.co.uk
Tue Nov 25 12:51:28 EST 2003
Thanks for your feedback -- see my responses below.
What is the process for peer review? Shall I revise my bits and resubmit
>From: Mark Curphey [mailto:mark at curphey.com]
>Sent: 23 November 2003 19:39
>To: Stuttard, Dafydd N (UK - London); 'Penny Major';
>Subject: RE: [OWASP-TESTING] Checking in
>This is a great start. I have a few suggestions / comments
>that may be worth
>1. In the description I think it may be worth accentuating the
>there is only a security issue in default files when they have security
>vulns. One of my pet peeves are consultants reports listing
>like documentation etc where there is no security issues at all. It's a
>housekeeping issue (I guess) but not a security one in my opinion.
Agreed -- there's nothing like trying to talk up a non-issue when you
haven't found anything decent :)
>2. In the "how to test" description I think it would be worth-while
>explaining that you are looking for the instance of the file.
>To do that you
>need to see an HTTP 200 or equivalent server response and this is
>essentially what tools like Nikto etc do. Maybe a http trace
>might be a good visual example....That leads neatly onto ...
Agreed. I mentioned this briefly in the Unreferenced Files section, but it
should be spelled out more fully in both.
>3. IMHO tools like Nikto and Nessus are really bad at finding
>That is because they can't tell the difference between an HTTP
>404 (or 400
>series server response) from a HTTP 200 carrying an HTML 404.
>As an example
>fire one of them off against OWASP.org and you'll find we have
>all the IIS
>files under the sun (on a Unix box!). The commercial scanners
>this by allowing users to define a 404.
Yes, Nessus does some basic 200 "not found" detection (and does it better
than one commercial scanner I've used!) but it isn't too clever. We should
list a few commercial tools as well.
>4. I am not sure white box and black box are good terms for this on
>5. How about tools like IIS lockdown that look for and remove
>sample files ?
>Is there an Apache equiv anyone knows about.
Not aware of one.
>1. This write up focuses solely on pen testing. How about comparing the
>deployed content to the CMS or app deployment tool? This is
>happens in enterprises in my experience. Maybe we should say
>that this is
>really a pen testing technique only ?
>2. Under blind guessing might be worth mentioning the HTTP /
>HTML 404 again.
>Great stuff though!
Agreed -- I'll spell out this point, with some techniques for automating
detection of 200 "not found" pages.
>3. I used to have a list of mutated extensions like ~bak from
>Vi and so on
>(that's wrong, I even forgot that). Maybe we could create that
>list as an
>appendix and we could build that into WebScarab. A simple XML
>be good such as
>4. Might be worth showing an example of making an HTTP call to list the
>directory contents where no default page for that dir has been
>Anyways great job, just a few thoughts I had !
If you have received this e-mail in error or wish to read our e-mail
disclaimer statement and monitoring policy, please refer to the
statement below or contact the sender.
This communication is from Deloitte & Touche LLP. Deloitte &
Touche LLP is a limited liability partnership registered in England and
Wales with registered number OC303675. A list of members' names
is available for inspection at Stonecutter Court, 1 Stonecutter Street,
London EC4A 4TR, United Kingdom, the firm's principal place of
business and registered office. Deloitte & Touche LLP is authorised
and regulated by the Financial Services Authority.
This communication and any attachments contain information which is
confidential and may also be privileged. It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s) please
note that any form of disclosure, distribution, copying or use of this
communication or the information in it or in any attachments is strictly
prohibited and may be unlawful. If you have received this
communication in error, please return it with the title "received in error"
to IT.SECURITY.UK at deloitte.co.uk then delete the email and destroy
any copies of it.
E-mail communications cannot be guaranteed to be secure or error
free, as information could be intercepted corrupted, amended, lost,
destroyed, arrive late or incomplete, or contain viruses. We do not
accept liability for any such matters or their consequences. Anyone
who communicates with us by e-mail is taken to accept the risks in
When addressed to our clients, any opinions or advice contained in
this e-mail and any attachments are subject to the terms and conditions
expressed in the governing Deloitte & Touche client engagement letter
Opinions, conclusions and other information in this e-mail and any
attachments which do not relate to the official business of the firm are
neither given nor endorsed by it.
More information about the Owasp-testing