Re: ie5 and .doc URLs

[tobkin () GOBLIN JAWS UMN EDU (Chris Tobkin)]

> Watching my apache's access.log, i could see that:
>
> (xxx meaning "stupid windows host belonging to a stupid big consulting
> company")
>
> xxx - "GET /~yoda HTTP/1.0" 301 230
> xxx - "GET /~yoda/ HTTP/1.0" 200 891
> xxx - "GET /icons/blank.gif HTTP/1.0" 200 148
> xxx - "GET /icons/back.gif HTTP/1.0" 200 216
> xxx - "GET /icons/unknown.gif HTTP/1.0" 200 245
> xxx - "GET /~yoda/document.doc HTTP/1.0" 200 83456
> xxx - "OPTIONS /~yoda HTTP/1.0" 301 230
> xxx - "GET /_vti_inf.html HTTP/1.0" 200 3042
> xxx - "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.0" 302 215
> xxx - "OPTIONS /~yoda/document.doc HTTP/1.0" 200 -

Actually, I noticed some odd behavior on my IIS servers when people
started using IE5.  They started complaining that they couldn't view
the .doc files and it would just come up with an Authentication Dialog
box..  It's been a while, but this is what I recall...

1)  ASP Script set Content-Type and sent the file (coincidentally, a .doc
file) to the IE5 browser..
2)  browser downloads the file
3)  browser looks for /_vti_inf.html
4)  if browser can find it, IE tries to invoke a FrontPage script on the
server to see if it can edit it.
5)  browser was not allowed to edit it (Error 302)
6)  browser tries OPTIONS (why, I don't know)
7)  browser turns control over to FrontPage (User-Agent changed) which then
tries to send a username and password (I don't recall if this was the
user's logon username/password combination or some default FrontPage
one, but I believe it was their NT logon.)  At this point it also dropped
the cookie that held onto its session in ASP.
8)  authentication fails - User is prompted for a username and password
that is valid on the server (dialog box comes up)
9)  If user authenticates correctly, the Word document comes up and user is
allowed to edit it.  If user doesn't authenticate correctly, then it just
drops the process and even though the file was downloaded in step 2, It
does not display it.
10) solution was to remove the files that it used to determine frontpage
either had been used or the extentions were installed. (/_vti_* )

As my fuzzy memories recall, the username/password sent was the NT logon
user/pass.  This could be used to harvest internal usernames and
passwords quite easily, and if the CGI was written correctly, the user may
never know that it was sent.  (If the CGI just accepted anything
other than the default -- or only when User-Agent was Frontpage and
just re-send the file they were trying to get, the authentication
dialog box wouldn't pop up and they would just think that they were
viewing the file as if it had been downloaded from any other site.  Also,
FontPage didn't need to be installed on the user's computer -- FrontPage
Express was built into IE5 it seemed.

Anyone else notice this stuff?

// chris
tobkin () umn edu

*************************************************************************
Chris Tobkin                                               tobkin () umn edu
Java and Web Services - Academic and Distributed Computing Services - UMN
Shep. Labs 190                                      Minneapolis, MN 55455
              ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
               "Fame is proof that people are gullible."
         - Ralph Waldo Emerson, poet, writer, and philosopher
*************************************************************************