Mailing List Archive

HTTP authentication methods
Currently, Nessus supports two authentication methods:
- "Basic", which sends "login:pass" encoded in Base64
Note that we do not support multiple "realms".
- SSLv3 client certificates

RFC2617 also defines the "Digest" authentication.
Supporting this would be much harder than the two previous one: as we
have to reply to a challenge, we should change the structure of all
the CGI plugins. I though of something like a http_send() function
which sends the request, handle the authentication challenge if
necessary, and returns the HTTP code.
It is possible to handle all this with a very dirty hack in the
send() and recv() functions, but I really do not like this.

However, AFAIK, Digest authentication is not (widely?) used. It
protects against password sniffing, but Basic authentication in a SSL
pipe is safer.
Do we need Digest? Is it worth the development cost?

Much more common is a classic login form. Once the username & password
have been posted, the server sets a cookie or adds a session ID in the
URL. The URL way is probably a bad idea and it seems that everybody
dropped it now.
The login form & session cookie could be implemented very easily.
We would just have to set:
- the form URL, method (probably POST) fields and values
- the cookie name, if necessary
Something like:
POST, /login.cgi, username=nessus&password=test&rememberme=1

(BTW, would a "cookie jar" be useful for any other purpose?)


Is there any other common web authentication method?

--
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/
Re: HTTP authentication methods [ In reply to ]
Along a somewhat similar vein. I'm in the process of writing a nasl-ized
version of wpoison which requires use of kb item www/port/cgis/ . It would
be nice if the different cgis were numbered...so you could loop through the
values one at a time. For my testing, I patched webmirror.nasl to separate
the www/port/cgis/ into separate entities so that I could do something like:

name = string("www/",port,"/cgis/0");
cgi = get_kb_item(name);
while (cgi) {
# do something with the cgi
i = i + 1;
name = string("www/",port,"/cgis/",i);
cgi = get_kb_item(name);
}

It gives me a little more flexibility on which of the cgis I wish to run
against....

Just my .02

John Lampe
https://f00dikator.hn.org/

"Knowledge will forever govern ignorance, and a people who mean to be their
own governors, must arm themselves with the power knowledge gives. A popular
government without popular information or the means of acquiring it, is but
a prologue to a farce or a tragedy or perhaps both."
--James Madison

----- Original Message -----
From: "Michel Arboi" <arboi@noos.fr>
To: <nessus-devel@list.nessus.org>
Sent: Wednesday, September 25, 2002 12:40 PM
Subject: Re: HTTP authentication methods


H D Moore <hdm@digitaloffense.net> writes:

> What would be absolutely awesome would be built-in
> NTLM authentication using the SMB credentials already specified. Of
> course NTLM authentication is rather painful to implement and makes
> normal Digest mode seem trivial in comparison.

Any information on this crap?

> These would be fields/cgi paths specified by the user before running the
> scan or parsed directly from the html?

I'd rather vote for the first solution (specified by user) unless you
really think that parsing the HTML is necessary :-(

> This could be implemented via the KB:
> set_kb_item(item:"www/80/data/cookies",value:"SessionID=X;Var1=Y");

What happens if there is already a value? Is the old one overwritten
(good) or is a list built (bad)?
Re: HTTP authentication methods [ In reply to ]
On Wednesday 25 September 2002 03:26 am, Michel Arboi wrote:
> Do we need Digest? Is it worth the development cost?

I doubt it, most Digest-enabled sites also support Basic because of the
two *different* Digest implementations in use between Netscape and
Internet Explorer. What would be absolutely awesome would be built-in
NTLM authentication using the SMB credentials already specified. Of
course NTLM authentication is rather painful to implement and makes
normal Digest mode seem trivial in comparison.

> Much more common is a classic login form. Once the username & password
> have been posted, the server sets a cookie or adds a session ID in the
> URL. The URL way is probably a bad idea and it seems that everybody
> dropped it now.

These would be fields/cgi paths specified by the user before running the
scan or parsed directly from the html?

> (BTW, would a "cookie jar" be useful for any other purpose?)

This could be implemented via the KB:

set_kb_item(item:"www/80/data/cookies",value:"SessionID=X;Var1=Y");

On the subject of the KB, it would be really nice if there was a way to
have bidirectional communication with the KB in the same plugin, make it
more of an active "registry" type system versus the pipe() it is now. A
slightly shorter-term goal would be to have the ability to pull all KB
entries at a given key into a nasl array (like for querying for a cgi in
every directory found by the directory scanner plugin).

> Is there any other common web authentication method?

One method growing in popularity is Microsoft's .NET Forms-Based
Authentication. Essentially it redirects every request to a directory or
resource to a login page first, then every request after that has to send
the ASP.NET-SessionID cookie. The only good thing about this method from
an implementation perspective is that the fields names and error
responses are usually standard/easy to find in the page.

I have a ton of notes on Forms-based auth if it sounds like worthwhile
goal, I need to finsih up the rest of the .NET plugins anyways ;)

-HD
Re: HTTP authentication methods [ In reply to ]
H D Moore <hdm@digitaloffense.net> writes:

> What would be absolutely awesome would be built-in
> NTLM authentication using the SMB credentials already specified. Of
> course NTLM authentication is rather painful to implement and makes
> normal Digest mode seem trivial in comparison.

Any information on this crap?

> These would be fields/cgi paths specified by the user before running the
> scan or parsed directly from the html?

I'd rather vote for the first solution (specified by user) unless you
really think that parsing the HTML is necessary :-(

> This could be implemented via the KB:
> set_kb_item(item:"www/80/data/cookies",value:"SessionID=X;Var1=Y");

What happens if there is already a value? Is the old one overwritten
(good) or is a list built (bad)?
Re: HTTP authentication methods [ In reply to ]
> H D Moore <hdm@digitaloffense.net> writes:
>
> > What would be absolutely awesome would be built-in
> > NTLM authentication using the SMB credentials already specified. Of
> > course NTLM authentication is rather painful to implement and makes
> > normal Digest mode seem trivial in comparison.
>
> Any information on this crap?

I was just reading the change log to libwhisker 1.5 last night and found that rfp
has implemented NTLM auth in LW. It may be a good place to check:

http://www.wiretrip.net/rfp/p/doc.asp/i7/d21.htm


___________________________________________________
http://www.cirt.net/
Home of Nikto
Re: HTTP authentication methods [ In reply to ]
On 25 Sep 2002, Michel Arboi wrote:

> H D Moore <hdm@digitaloffense.net> writes:
>
> > What would be absolutely awesome would be built-in
> > NTLM authentication using the SMB credentials already specified. Of
> > course NTLM authentication is rather painful to implement and makes
> > normal Digest mode seem trivial in comparison.
>
> Any information on this crap?

http://www.innovation.ch/java/ntlm.html
make sure to have a barf-bag ready before you start reading it

--Pavel Kankovsky aka Peak
"Welcome to the Czech Republic. Bring your own lifeboats."