WinHttpSendRequest security woes.

[Frossty]

I've seen people discussing security issues they've been having with the
WinHTTP functions, and decided to throw my problem into the hat :)

Here's the scenario. I have a machine in Domain A, and I'm trying to
communicate with a web service in Domain B. Internet Explorer can see the
data at the URL with no problem. Now, when I try to run the following set
of functions:

<code>
WinHttpSendRequest(hHttpRequest, WINHTTP_NO_ADDITIONAL_HEADERS, 0,
WINHTTP_NO_REQUEST_DATA, 0, 0, 0 );
...
WinHttpReceiveResponse( hHttpRequest, 0 );
...
WinHttpQueryHeaders( hHttpRequest, WINHTTP_QUERY_STATUS_CODE |
WINHTTP_QUERY_FLAG_NUMBER, NULL, &dwStatusCode, &dwBufferLen, NULL );
</code>

I get back a 401 for the dwStatusCode. Now things get interesting.

I then follow the examples I've seen and perform the following code,
expecting that the credentials that apply for my current session will apply
(I've also in prior code called WinHttpSetOption, setting
WINHTTP_AUTOLOGON_SECURITY_LEVEL_LOW for the AutoLogon policy) :

<code>
...
WinHttpQueryAuthSchemes( hHttpRequest, &dwSupportedSchemes,
&dwPreferredScheme, &dwAuthTarget );
...
WinHttpSetCredentials( hHttpRequest, dwAuthTarget, dwPreferredScheme, NULL,
NULL, NULL );
</code>

I have the above in a while loop, set to happen 20 times (this is quite
arbitrary, and is meant to deal with the time it takes for the
authentications to occur.) However, on the second iteration, the
WinHTTPQueryAuthSchema function starts returning error #4317. My code then
bombs out and tries no further. Note that I am re-using the HTTP request in
this loop (I am not tearing it down and creating a new one, because from
what I understand, that would undo my authentication changes.)

Any help would be greatly appreciated :)
Frossty.

[Stephen Sulzer [MSFT]]

Hello,

Can you please clarify the following:

1. When WinHttpQueryAuthSchemes returns the 4317 (ERROR_INVALID_OPERATION),
what is the status code indicated by WinHttpQueryHeaders?

2. When WinHttpQueryAuthSchemes does succeed, what is the value of
dwPreferredScheme? (2 means NTLM, 16 means NEGOTIATE).

3. Are you doing a GET or POST request (or something else)?

4. Are you using WinHTTP 5.0 (winhttp5.dll) or WinHTTP 5.1 (winhttp.dll) ?
On what operating system?

5. Are you setting the AUTOLOGON_POLICY option?

6. What is the proxy configuration?

7. Is your WinHTTP-based program running as the interactive (logged-on)
user? Or is it running under a different user account (e.g., a service)?

8. On the second iteration of the loop, is WinHttpReceiveResponse succeeding
(returning TRUE) or returning FALSE? If FALSE, what is the value of
GetLastError( ) ?

Thanks.

It would also help if you could provide a NETMON capture or WinHttp Trace
log of the scenario.

It is appropriate to continue to reuse the same Request handle while trying
to authenticate.

Regards,

Stephen Sulzer
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

"Frossty" <ma...@hfx.andara.com> wrote in message
news:euwxoqU0CHA.1636@TK2MSFTNGP10...

[Frossty]

1) WinHttpQueryHeaders has returned a 401 error.
2) THe value of dwPreferredScheme is returning 16 (NEGOTIATE).
3) I am sending a GET request for an ASP page.
4) I am using the WinHTTP 5.0 system, on Windows 2000 SP 3. The web server
is running on Windows XP SP1
5) I am setting the auto logon policy to
WINHTTP_AUTOLOGON_SECURITY_LEVEL_LOW.
6) I am running on a machine which is behind a Proxy server, but connecting
to another machine which also resides behind it. I have the Microsoft
Firewall Client installed as well.
7) It is being run as the interactive user (it's a simple command line
application.) However, in the future, the code will be called from another
user context using impersonation (potentially) in a service.
8) WinHttpRecieveResponse always return TRUE.

Note also that my original assertion that it was on the second loop that
WinHttpQueryAuthSchemes is not accurate. It is actually on the third
iteration that the function fails.

Many thanks for a response (and so timely! :)

"Stephen Sulzer [MSFT]" <ssu...@online.microsoft.com> wrote in message
news:#2vIX3a0CHA.2184@TK2MSFTNGP09...

[Stephen Sulzer [MSFT]]

So far nothing suspicious.

One important thing to confirm: After you call WinHttpSetCredentials, resend
the request, and call WinHttpReceiveResponse, you must call
WinHttpQueryHeaders during each iteration to check for the new status code.
WinHttpQueryAuthSchemes will return the 4317 error code when authentication
succeeds and the server responds with 200. So you cannot rely on
WinHttpQueryAuthSchemes to indicate when authentication has succeeded. It
wasn't clear from your original problem description that your code is
checking for the new status code using WinHttpQueryHeaders during each
resend request iteration. The example given in the reference documentation
for WinHttpSetCredentials shows this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winhttp/http/winhttpsetcredentials.asp

If that is not the issue, then a WinHTTP Trace log might help.

Regards,

Stephen Sulzer
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

"Frossty" <ma...@hfx.andara.com> wrote in message

news:OetHD#c0CHA.1768@TK2MSFTNGP12...

[Frossty]

Actaully, if we run that example, we run into the problem (that is, the
example doesn't seem to work in this particular case.)

"Stephen Sulzer [MSFT]" <ssu...@online.microsoft.com> wrote in message

news:uDOOzzm0CHA.2188@TK2MSFTNGP10...