Re: [PATCH] showHTMLTitle.nse - bugfix and a few improvements

[jah <jah () zadkiel plus com>]

On 03/10/2008 16:18, Sven Klemm wrote:
> jah wrote:
> | Some more thoughts on following a redirection (which I never considered
> | would turn out to be such a pain in the arse).
> |
> | What I hoped to achieve by using http.get_url() was to check that the
> | redirection wasn't to a different box and then to pretty much follow any
> | URI given.  So really, the last iteration was checking the host and then
> | just making sure that the URI was sane for get_url().
> | For example, if there was no scheme present: location = host.com/ it
> | would add one.  Similarly for path.
> |
> | This would allow us to follow redirects where the scheme, authority
> | (perhaps the redirect includes userinfo - user:pass@host ), host
> | (perhaps we're being asked to use the hostname rather than the IP), port
> | or path changes.  In theory, that is, because it turns out that
> | get_url() ignores anything in url.authority except the hostname/IP and
> | overrides the port number based on the scheme (http = 80, https = 443).
> |
> | On top of that, I've got some doubts as to whether we should even follow
> | a redirection to a different port.  If the user didn't specify the port
> | in a scan, should we override their choice?  Then again perhaps they'd
> | like to know about this extra port.
> | A common redirection is to https on port 443.  Perhaps this should be
> | the one exception to the rule that enforces no deviation from physical
> | box and the port specified.  Perhaps there should be no exceptions and
> | just report the location to the user - as is done if we can't determine
> | whether we're being redirected to a different box.
> |
> | This is what I'm tending toward:
> | Disallow redirection to a different box or where we can't determine if
> | the redirection is to a different box.
> | Allow redirection to port 443 only if port 443 is not one of the user
> | specified ports (since the script will also run against that port).
> | Disallow redirection to any other port.
>
> I think we should never follow redirects unless it's the same port.
> Otherwise the script output will not be relevant to the port but refer
> to something completely unrelated. If it redirects to another port we
> should show the target for the redirect in script output.
Well, not completely unrelated.  The service on that port did, after
all, redirect us.  Nevertheless, you make a good point.  The port script
result would be misleading in these cases.  It would certainly be less
hassle to ignore redirection to another port.
> | I'm still not sure about these cases:
> | Allow redirection where userinfo is given.
> | Allow redirection where no part of the URI changes (server sets a
> | cookie) or where a query string is added to an otherwise unchanged URI.
> |
> | Obviously, a debug statement would alert the user to any redirection
> | found whether followed or not.
>
> I am not sure what you mean by debug statement. I think if we don't
> follow a redirect we should show the URL being redirected to in normal
> script output.
Given that the purpose of the script is to extract an html title, I
prefer not to see any output if there is no content to extract from and
a message if there was content, but it wasn't possible to extract an
html title.  In the case of redirection I opted for a print_debug()
statement to inform the user rather than cluttering the port script
result with what might be a long URI.  Anyone else have an opinion on this?
> | I'm still in two minds about implementing a DNS lookup which might yield
> | a vhost for the box in most cases and yield the name of a related box in
> | others.
>
> The redirect to a host which does not match ip,name or targetname is
> very likely a vhost. A DNS lookup would verify this. Doing a DNS query
> would make the script belong to the external and currently we don't
> have "external" scripts in the default category. I am not sure about
> this either. Finding vhosts is certainly extremly useful.
I'd not thought of that and it seems a good enough reason not to do
DNS.  At least we won't be discarding this information, we just won't
validate it as part of this script.

Cheers,

jah




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