Re: [PEN-TEST] HTML source code and authentication

[Bennett Todd <bet () RAHUL NET>]

2000-12-18-14:12:41 Skinner, Tim L.:
> #<form name="signon" action="/scripts/ibank.dll" method=post>
> #<INPUT TYPE ="HIDDEN" NAME=Func VALUE="SignOn">
> #<INPUT TYPE=HIDDEN NAME=Frames VALUE="150">
> #<INPUT TYPE ="HIDDEN" NAME=homepath VALUE="cu3">

Presumably there are some other fields as well, before the /form
that closes the section off.

Depending on how they work, there may or may not be a problem.
Hidden fields are a fine way to pass information from one invocation
of a CGI to another, as long as the information doesn't have to be
secret. It's not obvious to me from peeking at that fragment whether
that info has to be secret or not.

Using hidden fields as an alternative to HTTP Basic Auth (or
cookies) for managing "login sessions" requires care; if you're
going to do it, arrange for the contents of the fields you download
to be time- and ipaddr- restricted, random strings of bits, used to
key a database kept on the server. Regard the info as completely
public, because some especially stupid web browser designers will
lovingly deposit all those "hidden" field values into user caches,
where they're exposed to anybody who can attack the machine --- and,
needless to say, anybody who runs one of those browsers will be
awfully easy to attack.

At least, so I've been told; I don't use a web browser that deposits
hidden field values on disk, but when I tried using 'em for a simple
auth model, one of our auditors claimed to be able to find the
passwords I was borfing about in their browser's disk cache.

I'd tend to recommend against attempting such cleverness, use HTTP
Basic Auth and let the server implement it for you, since at least
when browser writers screw _that_ up there's no question that it's
a bug; when it comes to caching form data, sufficiently stupid
browser authors defend their behavior as being appropriate from some
psychopathic and deranged set of design assumptions.

-Bennett

Attachment: _bin
Description: