RE: http-methods & http-trace NSE Script Enhancement Ideas

[King Thorin <kingthorin () hotmail com>]

Date: Fri, 25 May 2012 18:27:00 +0200
Subject: Re: http-methods & http-trace NSE Script Enhancement Ideas
From: patrik () cqure net
To: kingthorin () hotmail com
CC: david () bamsoftware com; nmap-dev () insecure org



On Fri, May 25, 2012 at 3:29 PM, King Thorin <kingthorin () hotmail com> wrote:





> Date: Thu, 24 May 2012 13:45:30 -0700

> From: david () bamsoftware com

> To: kingthorin () hotmail com

> CC: nmap-dev () insecure org

> Subject: Re: http-methods & http-trace NSE Script Enhancement Ideas

>

> On Wed, May 23, 2012 at 08:17:03AM -0400, King Thorin wrote:

> >

> > I was just looking through some online docs and some nmap results. I've

> > never seen a server that includes public or allow header(s) on a

> > redirect response [maybe my experience is limited?]. It seems to me that the http-methods NSE should follow

> > redirects (HTTP 301, 302, 303) in order to perform the necessary OPTIONS

> >  request on a page/resource that's providing a HTTP 200.

>

> Ideally the redirect handling would work the same as the built-in

> handling of the http.get and http.head methods. See this earlier

> discussion:

>

> http://seclists.org/nmap-dev/2012/q1/338

>

> David Fifield



Hi David,



I definitely agree with this idea. Someone else mentioned it yesterday. Unfortunately:

1) I'm not a developer. Though I understand code at a beginner or "maybe" intermediate level and can write some kludgey 
bits I don't write code on a daily basis. Looking at http://nmap.org/nsedoc/lib/http.html yesterday did not clarify 
redirect_ok or MAX_REDIRECT_COUNT for me at all.


2) The existing redirect functionality (based on the thread you linked) only seems to cover get and head not 
http.generic_request.



3) I've done some intext and site:nmap.org googling looking for existing NSEs that leverage the existing functionality 
but they seem pretty rare and are only get/head based.




_______________________________________________

Sent through the nmap-dev mailing list

http://cgi.insecure.org/mailman/listinfo/nmap-dev

Archived at http://seclists.org/nmap-dev/


I see two options;1. The script is adapted not to use the generic_request method anymore but rather use the method 
specific function such as get, put, head that already have redirect support. A mapping would have to be made in the 
script to know what function to use for what method and the missing method specific functions would need to be created 
(more or less copied from existing ones, eventually leaving out cache support).
2. The script continues to use generic_request and implements the redirect function either locally or by removing the 
local keyword infront of those functions in the http library so that their visible to the script.

Personally, I think I would go with alternative 1.
//Patrik
-- 
Patrik Karlssonhttp://www.cqure.net
http://twitter.com/nevdull77


Hi Patrik, I'm confused by your suggestion #1 it seems to suggest two different ideas.

We can't use a method specific function to perform a request using a different method. (i.e.: you can't do HTTP TRACE 
via HTTP GET....). 
What mapping would be required in #1 if the method
 specific functions were added to the base library (i.e.: http.trace and
 http.options)?

Maybe I'm missing something but wouldn't it make the most sense to extend the existing redirect functionality within 
the HTTP library to generic_request with the default set to false? Then handling of redirection would be possible on 
any HTTP method (current or future).

Note, I haven't looked into this at all but with regard to the current redirect functionality if the redirect does not 
meet one of the base libraries requirements then it might be nice to pass those details back to the calling function or 
script. i.e.: if the redirect isn't followed because it's off-domain or off-host (port, protocol, etc) it would be nice 
to the calling function or script to be able to report such (esp. in verbose mode....for example "Redirect not followed 
due to off-domain location.").

                                          
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/