Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: http-methods & http-trace NSE Script Enhancement Ideas
From: Patrik Karlsson <patrik () cqure net>
Date: Fri, 25 May 2012 20:45:05 +0200

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 Karlsson
http://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

-- 
Patrik Karlsson
http://www.cqure.net
http://twitter.com/nevdull77
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault