mailing list archives
Re: hexify() problem in http-passwd.nse
From: Joao Correa <joao () livewire com br>
Date: Sat, 30 May 2009 06:17:58 -0300
I've made a little confusion and I've just noticed at  that the
tags <code> and </code> are just rendering tags, and that there's no
meaning associated to it.
Anyway, I'm still in doubt about in which cases the script should be
 - http://nmap.org/book/nsedoc.html#nsedoc-tags
On Sat, May 30, 2009 at 5:50 AM, Joao Correa <joao () livewire com br> wrote:
I've just realized that the script is for trying to retrieve the
passwd file using the path as a parameter to a web page (described as
<code>/etc/passwd</code> on the comments) and not directly as a URI,
making necessary the use of hexed chars.
Sorry about the previous e-mail.
On Sat, May 30, 2009 at 5:41 AM, Joao Correa <joao () livewire com br> wrote:
I've been testing the script http-passwd.nse and I've found the
The script uses a function called hexify to transform the address into
a URI encoded address, including transformations to the "/" (slashes),
making it something like "www.address.com%2F%2Fetc%22Fpasswd" . I've
noticed that the apache server where I've been making tests was always
returning 404 error to such request. I've removed the hexify function,
and the script started working perfectly.
I believe that such request (with hexed "/") was valid somewhere ago
in time and was not recently tested, or is valid in another web
server, what justifies the use of the hex function. Anyway, according
to RFC 3986 , that dates from 2005, the substitution of %2F (hex
encoding of "/") is not equivalent to /, since it is a reserved
In time, setting the hexify function to replace "/" for %252f make it
work fine again. Anyway %25 means "%" and I think that such
substitution is quite redundant.
I'm thinking about removing the hexify function from the scripts, but
I don't know if it will affect any other web server.
Do someone uses this script daily or in a different web server and
have any consideration?
 - http://tools.ietf.org/html/rfc3986#section-2.2
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org