idiosyncrasies w/ scripted login security

lydia lydia at HULmail.Harvard.EDU
Thu Jul 9 19:36:46 EDT 1998


This question is primarily for those of you who write perl cgi scripts
that handle user authentication to remote sites, though others may be
able to offer useful perspectives on the subject. 

One of the simplest methodologies for writing such scripts involves,
as its final step, sending the user a redirect in the form of an HTTP
"Location:" header -- for example,

  print "Location: http://foo.org/login.cgi?username=xx&password=yy\n\n";

We have avoided this strategy in the past, partly because establishing
a full HTTP connection via the LWP library instead allows us much
fuller information for logging purposes, but also because the
"Location:" trick has not seemed fully secure. To wit, whenever I have
tested scripts that use the above syntax, the URL that displays in the
client browser's location window is the same as the one I sent, thus
rendering the username and password visible to the end user. 

Often, the vendors I deal with are unable to replicate this behavior,
insisting that the URLs their browsers display are utterly innocent of
password data. Occasionally one of them is able to elicit the same
result I'm seeing; I got the following helpful diagnostic information
from one such person:

> I've had a look at it using various different machines and servers.
> The results don't seem to be consistent, sometimes the URL shown is
> the final one with the username and password and sometimes it's the
> first one as I thought it would be.

When I asked about any pattern among the results, he said,

> It seems to be dependent on the version of Netscape you use. A
> couple of the 4.0x versions don't show it, whether this is a bug
> which they've fixed yet I don't know. I've now upgraded to 4.05 and
> I get the same results you got.

Now, this theory of browser-dependence made plenty of sense at the
time, and still does--and I certainly don't have a reasonable
alternate explanation. However, I now have need of other theories.

Today I managed to get the same browser on the same machine to display
both behaviors in a single afternoon. I cannot identify any
differences either in browser settings or in perl syntax that could
possibly account for the change. This afternoon, for the first time,
my browser started behaving like everyone else's (displaying a secure
URL rather than one containing a password), and I'm completely
stumped. And now I can't get it to return to its usual behavior.

Has anyone else seen both of these display behaviors? If so, have you
gotten any farther in identifying the underlying trends? Can you
suggest any new avenues of investigation?

Many thanks for any light you can shed. 

~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
 Lydia Ievins, Systems Librarian          Office for Information Systems
 phone 617/495-3724; fax 617/495-0491     Harvard University Library
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~




More information about the Web4lib mailing list