[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nmap-dev
Subject:    Re: http-methods.nse implementation
From:       David Fifield <david () bamsoftware ! com>
Date:       2011-04-28 3:58:22
Message-ID: 20110428035822.GE5793 () gusto ! bamsoftware ! com
[Download RAW message or body]

On Wed, Apr 27, 2011 at 07:20:39PM -0700, David Fifield wrote:
> On Tue, Mar 08, 2011 at 02:57:57PM +0100, Vlatko Kosturjak wrote:
> > On 03/08/2011 02:49 PM, Rob Nicholls wrote:
> > > On Tue, 8 Mar 2011 15:33:48 +0200, Josh Amishav-Zlatin wrote:
> > >> Would it make more sense for the
> > >> script to have a base list of methods that it checks for regardless of
> > >> whether OPTIONS is enabled or not and then appends that list based on
> > >> the results of an OPTIONS request?
> > > 
> > > I'd prefer not to trust OPTIONS at all, and perhaps rename the existing
> > > option or add something like http-methods.force or http-methods.thorough
> > > to test a long hardcoded base list of methods like you suggest. The
> > > current "retest" option doesn't really retest the methods, it simply
> > > performs a more thorough test based on the original OPTIONS response
> > > (which, as you point out, could be inaccurate).
> > 
> > I think we discussed this already some time ago:
> > http://seclists.org/nmap-dev/2010/q1/618
> > ...and I remember, decision was to have it like this.
> 
> I don't know, I think it's fine to test from a static set of method
> names (including invalid names). If someone writes a good patch I think
> we'd accept it. It just perhaps shouldn't be default.

Oops, it had been a while so I forgot that Josh had already written a
patch:

http://seclists.org/nmap-dev/2011/q1/936

I can't get the patch to apply cleanly, and it has some whitespace
problems. It might make sense to keep the old argument name
http-methods.retest instead of replacing it with http-methods.verify,
but in any case the new behavior has to be documented.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/
[prev in list] [next in list] [prev in thread] [next in thread]