AW: http.lua Bug and Fix

[Sebastian Prengel <sebastian.prengel () googlemail com>]

-----Ursprüngliche Nachricht-----
Von: David Fifield [mailto:david () bamsoftware com] 
Gesendet: Donnerstag, 24. Februar 2011 21:20
An: Sebastian Prengel
Cc: nmap-dev () insecure org
Betreff: Re: http.lua Bug and Fix

 

On Thu, Feb 24, 2011 at 10:25:00AM +0100, Sebastian Prengel wrote:

> Hello Dev-Team,

>

> I need to do some changes to enable cookie support of "http.lua". All

> changes are marked with "CHANGE CHANGE CHANGE". I use Zenmap 5.50 on
windows

> XP. Hope it is also useful for you.

>

> --- nselib/http.lua

> +++ nselib/http.lua

> @@ -267,7 +267,7 @@ local function validate_options(options)

>      elseif(key == 'cookies') then

>        if(type(value) == 'table') then

>          for cookie in pairs(value) do

> -          for cookie_key, cookie_value in pairs(value) do

> +          for cookie_key, cookie_value in pairs(value[cookie]) do

>              if(cookie_key == 'name') then

>                if(type(cookie_value) ~= 'string') then

>                  stdnse.print_debug(1, "http: options.cookies[i].name
should be a string")

> @@ -283,6 +283,11 @@ local function validate_options(options)

>                  stdnse.print_debug(1, "http: options.cookies[i].path
should be a string")

>                  bad = true

>                end

> +            elseif(cookie_key == 'expires') then

> +              if(type(cookie_value) ~= 'string') then

> +                stdnse.print_debug(1, "http: options.cookies[i].expires
should be a string")

> +                bad = true

> +              end

>              else

>                stdnse.print_debug(1, "http: Unknown field in cookie table:
%s", cookie_key)

>                bad = true

 

Thank you for taking the time to submit a patch. These changes look

correct. I think the first hunk is better written this way, which I have

committed:

 

--- nselib/http.lua

+++ nselib/http.lua

@@ -266,8 +266,8 @@ local function validate_options(options)

       end

     elseif(key == 'cookies') then

       if(type(value) == 'table') then

-        for cookie in pairs(value) do

-          for cookie_key, cookie_value in pairs(value) do

+        for _, cookie in ipairs(value) do

+          for cookie_key, cookie_value in pairs(cookie) do

             if(cookie_key == 'name') then

               if(type(cookie_value) ~= 'string') then

                 stdnse.print_debug(1, "http: options.cookies[i].name should
be a string")

 

okay no problem.

 

> @@ -1038,11 +1043,17 @@ local function build_request(host, port, method,
path, options)

>    }

>  

>    if options.cookies then

> -    local cookies = buildCookies(options.cookies, path)

> +    local cookies = buildCookies(options.cookies) ---CHANGE CHANGE CHANGE
delete path because cookie.path was empty

>      if #cookies > 0 then

>        mod_options.header["Cookie"] = cookies

>      end

>    end

 

I don't understand the reason for this one. If path is nil, then taking

it out of the function call is the same as leaving it in. Is it instead

the empty string or something? What error message were you seeing?

 

The web server I connect delivered cookies with empty path so all cookies
were removed because “not path or string.match(ck["path"],".*" .. path ..
".*")” = FALSE in buildCookies. I think if somebody put cookies in options,
they should be sent. I am fine with deleting path in function
buildCookies(cookies, path).  

 

> +

> +  ---CHANGE CHANGE CHANGE add section Referer in http header when path
and cookie set

> +  if path and options.cookies then

> +   mod_options.header["Referer"]=path

> +  end

> +

>    -- Only Basic authentication is supported.

>    if options.auth then

>      local username = options.auth.username

 

My first impression is that control of Referer should be left to the

script author. Is this a particular web application that needs Referer,

or does this requirement apply in general?

Okay I put this in my script.

 

 

David Fifield

 

Regards

Sebastian

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