Re: http.lua Bug and Fix

[David Fifield <david () bamsoftware com>]

On Fri, Feb 25, 2011 at 10:55:13AM +0100, Sebastian Prengel wrote:
> > -----Ursprüngliche Nachricht-----
> > Von: David Fifield [mailto:david () bamsoftware com] 
> > On Thu, Feb 24, 2011 at 10:25:00AM +0100, Sebastian Prengel wrote:
> >
> > > @@ -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).  

I see. I think it's not right to completely ignore the path. It's
possibly better to try to interpret an empty path, which according to my
reading of RFC 2965 is not legal.

Python's cookielib.py has
    if not req_path.startswith("/"):
        # fix bad RFC 2396 absoluteURI
        req_path = "/"+req_path
I guess that's reasonable. What do you think?

That said, the buildCookies path matching looks wrong to me.
    if not path or string.match(ck["path"],".*" .. path .. ".*") then
The path should only be matched at the beginning of the string, not just
anywhere. And the patch should be escaped for Lua pattern
metacharacters. Is anyone willing to look over the RFC, check if this is
correct, and send a simple patch?

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