Re: Thumbnail security problem?

From: Hector Santos (
Date: 11/16/03

Date: Sun, 16 Nov 2003 02:05:12 -0500

Robert, thanks for your input, but I don't believe you are following what I
have written or maybe you don't understand the HTTP 1.0 Basic Authentication
standard and how it works.

First, all resource request (GET, POST, etc) which require authentication
will receive a 401 response from the web server.

For example:

When I manually type the following URL in the IE address bar or double click
it in web page, etc:


the IE browser will sent the following UNAUTHENTICATED request

-------Request----------- time: 0
GET /client?personal.wcn HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/, application/, application/msword,
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
Connection: Keep-Alive

It is unauthenticated because there is no Authenticate: Basic XXXXXXXXXXXXXX
line that contains the user's credentials.

Now the web server determines that the resource, /CLIENT?PERSONAL.WCN is a
restricted resource and requires that the user login. So the web server
sends 401 response telling the IE BROWSER to pop up a dialog to get the
user's name and password:

-------Response---------- time: 671
HTTP/1.0 401 Unauthorized
Expires: -1
Last-Modified: Sun, 16 Nov 2003 06:23:58 GMT
Content-Length: 230
Server: Wildcat/v5.7.450.9b10
Cache-Control: no-cache
Content-Type: text/html
WWW-Authenticate: basic realm="Santronics Research"
Date: Sun, 16 Nov 2003 01:23:58 GMT

followed by HTML data that will show the "unauthorized message" to the user
when the user cancels or fails to login.

-------Send Data--------- time: 10
<!-- unauthorized.htm-->
<h3>Wildcat! Interactive Net Server - Sorry, unauthorized!<h3>
<img src="/public/graphics/PoweredByWINS.gif" width=88 height=31
alt="Powered by WINSERVER!" border="0">

Now, at this point the browser will POPUP the LOGIN BOX and assuming the
user doesn't cancel and types in username and password and hits OK, the
browser will then resends the request but this time includes an additional
header lines that include the authentication: basic line:

-------Request----------- time: 3334
GET /client?personal.wcn HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/, application/, application/msword,
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
Connection: Keep-Alive

Obviously, I Xed out the encoded credentials because it can easily be

Now this time the web server repeats the resource check and sees that an
authorization line was provided. If all checks out, a successful 200 code
response is sent followed by all the web page information, etc. Here is
just the header response:

-------Response---------- time: 401
HTTP/1.0 200 OK
Expires: -1
Last-Modified: Sun, 16 Nov 2003 06:24:02 GMT
Content-Length: 5586
Server: Wildcat/v5.7.450.9b10
Cache-Control: no-cache
X-BBS-Name: Santronics Research
Content-Type: text/html
Date: Sun, 16 Nov 2003 01:24:02 GMT

followed by the web page html code to display, etc.

>From this point forward, until the user literally CLOSES the browser, the
credentials are sent with each and every request to the web server. It is
only when the BROWSER is closed, is the credentials released.

Ok, now that you see the basics, the problem we are seeing is as follows:

Via Windows Explorer, when you view an URL shortcut which is a file with
the extension URL, such as PERSONAL.URL, containing the following


and when you PUT your cursor over the shortcut, the PAGE is displayed as if
you were logged in.

That's the problem, that's the flaw.

However, if you double click it, as you expect it would, it will go thru
the authentication process of asking you to login. That is correct logic.

So where did this "Viewable Page" come from? The cache?

Ok, so I start the browser, clear the cache, as well as delete all offline
context and close the browser again.

I repeat the explorer process again, and viola, same problem.

So the next question is where is EXPLORER getting the credentials from so
that it can use it with the URL shortcut?

We don't know.

Lets put this on the back burner for the moment.

You ask if this is a CLIENT and SERVER issue. Well, if its not obvious yet,
I did the following:

a) I delete the cache, offline files again, close browser.
b) I restarted the WEB server

and repeated the process, now if we look in the HTTP log files, we see that
the VERY FIRST request is the GET request with the authentication line. It
did not send an unauthenticated request. There is no server 401 response. It
is a direct authenticated GET request with a successful server 200 response.

So obviously, this is not a server issue but rather a client issue.

I understand you may not be able to repeat it on your IIS server. I'm sure
there plenty of possible factors such as NTLM authentication, etc. But it
is a real bug with 2 more beta testers being able to repeat the problem.

The fact remains that the FIRST request to the server is an authenticated
request with the credentials provided so that the server can immediately log
in the user and send the web pages.

This flaw only occurs in the Explorer technology to display a "example
picture" of what the web site will look at.

Obviously, the issue is one of knowing where the credentials are being
stored persistently. It is grabbing it from somewhere on the machine or a
process in memory and it certainly not coming from the server because once
again, even before the server is in the picture, the credentials is
retrieved and sent with the very first request.

Hope this explains it better

Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
"Robert Moir" <> wrote in message
> Hector Santos wrote:
> > Robert,
> >
> > I have been able to repeat this bug at will.  Out of curiously, I
> > asked beta testers in our beta forum to test it as well since our web
> > server is 100% Basic Authentication requirement.   Thus far I got
> > another people to repeat the problem.  Its the weekend so I am sure
> > there will be more to follow. Here is his messages to prove it:
> Thats odd. Maybe theres another ingrediant which I don't have for some
> reason but to say that I don't and everyone else in a random sample does
> pushing it a bit. I'd suspect that the sites I was testing against were
> basic authentication sites except that i set one of the two up myself on a
> server i built and run myself, so im very certain of that one.
> It must be credential caching on the client i'd have thought, unless
> everyone is testing against the same kind of web server and its a web
> bug (I'm testing against IIS6 btw).
> Regards
> Rob