On 2/19/07, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Fri, 16 Feb 2007, Achint Mehta wrote:
>
> > 3. Then the function Curl_output_digest (http_digesti.c) is called which
> > checks whether we have nonce value for this request (if(!d->nonce)).
> Since
> > we don't have a nonce value we return from this function without
> encoding a
> > new Authorization header. However, the previous Authorization header is
> > still present in conn->allocptr.userpwd field. And may be this field is
> used
> > eventually in the GET request.
>
> >>But sending the previous auth header can't be considered to be terribly
> bad,
> >>can it? I mean, libcurl can't know for what paths on the server when it
> needs
> >>a new auth negotiation to take place.

You are right. In a perfect world the web-server would respond back with
401, since the nonce value would not be valid anymore ( and possibly set the
stale true if the request is for the same URL). This is not a bug on the
libcurl side, but when I saw this behaviour I thought that we might be
forgetting to clear the previous Authorization header.
I thought this behaviour might not be desirable under the following scenario
(which I admit won't occur under normal cicrumstances):
1. The application is sending requests for single URL. Then the next
immediate GET request would have the previous Authorization header. This can
qualify as a replay attack. An over-cautious web server might observe this
over a long period of time and may take a defensive action.
2. RFC 2617 (3.2.2) says the digest-uri should be same as the request URI of
the request line. If the next GET is for different URL then using the
previous authorisation yield different digest-uri and request URI. I am not
sure how would the server is supposed to react to this.

In a non-perfect world a web server might generate the same nonce value
every-time (which I am witnessing right now for a specific URL). So if a GET
request with credentials URI succeed, then a subsequent GET request with
invalid credentials also succeeds. This might look good first but the user
is still under the impression that the wrong credentials are working. Though
this is a bug at web-server.

I understand that just because a scenario is not working for me, doesn't
mean that the library is broke everybody has to fix this. I hope this mail
chain is of some help to some-one who faces a similar situation.

However, I am not able to think of the scenarios where this behaviour
(sending the previous Authorisation header) would be desirable.

>>The only thing is that libcurl should then of course react properly on the
> 401
> >>response as it would if no auth header at all had been sent.
>
> > 4. I changed the code in function CreateConnection where the new
> user-name
> > and password are being copied to the connection structure, to free the
> > allocptr.userpwd field and set it to NULL.
>
> >>Since this is HTTP, it is perfectly fine for an application to change
> user and
> >>password between requests and they can still re-use the same connection
> fine,
> >>so I don't think this sounds like the correct procedure. Re-using a HTTP
> >>connection does not imply the same user + password.

You are right. I also did not intend to keep the previous username and
password. I only want to say that it wouldn't harm to clear the
allocptr.usrpwd field which contains the authorization header. Though the
field name is usrpwd but it contains the complete authorisation header
encoded in the Curl_output_digest function in http_digest.c. The code
snippet I provided still copies the new user name and password and in
addition to that it clears the usrpwd field.

On a separate note, I (and almost everyone would ) have found libcurl to be
a swiss knife. It is extremely simple yet vast in functionality. Even the
code has been very modularised and well commented making it easy to
understand. I had to go into the libcurl code for some trivial things and I
do apprecaite the neatness of the code which saved me lots of time and
trouble.

Thanks Daniel for taking time to respond to my mail and creating the curl
library.

Regards,
Achint
----------------------------------------------------------------------------------------------------
"I hold open source people to higher standards. They are supposed to be the
people who do programming because it's an art-form, not because it's their
job."
-Linus Torvalds
----------------------------------------------------------------------------------------------------
Received on 2007-02-19