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

[King Thorin <kingthorin () hotmail com>]

From: kingthorin () hotmail com
To: patrik () cqure net
CC: david () bamsoftware com; nmap-dev () insecure org
Subject: RE: http-methods & http-trace NSE Script Enhancement Ideas
Date: Sun, 27 May 2012 20:55:26 -0400







Date: Fri, 25 May 2012 20:45:05 +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



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)?

Sorry, I thought the answer was pretty straight forward, reading it again I realized maybe not :) No obviously we can't 
do TRACE with GET, that was what I tried to get at with "and the missing method specific functions would need to be 
created". For the mapping it could be a simple lua table:

local mtof = { ["TRACE"] = http.trace, ["GET"] = http.get }  

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).


I guess you could do that, but if I remember previous discussions correctly, we wanted to keep the generic_request as 
"raw" as possible and have the caching and redirect code in the method specific functions.
 
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.").


                                          

Yes, that would be a nice addition and it shouldn't be too hard to add.
//Patrik

Thanks Patrik, I think we're on the same page now, and I can understand the argument or thought process for keeping 
generic_request "raw".



2012-May-30

So now I'm back to wondering who "owns" the http lib and what the best method is to get these idea implemented/things 
changed?

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