Date: Fri, 6 Feb 1998 01:01:28 -0800 (PST) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: Andrew McNaughton <andrew@squiz.co.nz> Cc: hackers@FreeBSD.ORG Subject: RE: WebAdmin Message-ID: <Pine.LNX.3.96.980205233803.10973A-100000@phobos.illtel.denver.co.us> In-Reply-To: <v02120d00b0ff5030c15f@[203.96.56.128]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Feb 1998, Andrew McNaughton wrote: > > > >I've written a couple of web-based SQL databases, and I have been able > >to sucessfully encode enough state into the webpages themselves to make > >the databases useable and stable. > > I'm new to FreeBSD, but I've spent the past year doing CGI programming, > including a system for administering a database of users (not users in the > sense of being in /etc/passwd though). > > The first time I wrote an authentication system, I used a hidden session > key as suggested above. For _authentication_ one should use HTTP protocol authentication -- "Basic" authentication works perfectly for that purpose. For _session control_, if one is used, session-specific URLs, hidden fields and cookies can be used, however the atomic operations by themselves don't require it -- they can be done in one request. Long interactive data submitting/editing procedures require sessions to be kept if the same userid (known through authentication) is allowed to have simultaneous multiple sessions, however the final form submission can just contain all involved parameters in hidden fields. HTTP user that performs automated transactions (if they are allowed, as in my proposed HTTP-based remote administration model) probably should never be the same as human HTTP user, and only human users can have long interactive sessions while automated transactions should be done in one form submission with no context outside of it, so only browsers or other HTTP-capable utilities that human users use should work with sessions. Therefore if no _human_ user is allowed to have multiple sessions simultaneously, only authentication information can be used to refer to session state. If human HTTP users are allowed to have multiple sessions with the same username at the same time on the same host, session control mechanism should be used. In any case session control is not a replacement for authentication. > It's messy, mostly because it gets lost any time the user visits a static > page as tends to happen when they go to look at some documentation. If > users are encouraged (or even allowed) to back up using the browser's back > button, then problems occur with form data being resubmitted in order to > view a page again. It's somewhat browser dependent. To prevent this, > session keys should probably be changed whenever data is submitted, though > I haven't yet implemented this. Or processing should be designed to leave state unaffected by every resubmission, if this model is used. > It's also likely that hidden variables in pages will wind up being cached > somewhere, in spite of any attempts to prevent it. Sessions must expire on > the server. > > I currently use Netscape cookies to store session keys, which simplifies > the above problem. I keep session records on the server which (if the user > is logged in) refer to the appropriate user records. They also store the > IP associated with the connection, and the time when the session key was > last used. IP addresses are unreliable -- not only multiple users can be connected from the same address, the same user in the same session can have requests coming from different hosts (multiple proxy servers, reconnected dynamic IP when session was active, etc). > This works well enough. > > The Perl CPAN module CGI::MiniSvr implements another approach. This is > from it's documentation: > > > This file implements the CGI::MiniSvr object. This object represents an > > alternative interface between the application and an HTTP deamon. > > > > In a typical CGI scenario the interface is just a collection of environment > > variables passed to a process which then generated some outout and exits. > > The CGI::Base class implements this standard interface. > > > > The CGI::MiniSvr class inherits from CGI::Base and extends it to implement > > a 'mini http daemon' which can be spawned (forked) from a CGI script in > > order to maintain state information for a client 'session'. > > > > This is very useful. It neatly side-steps many of the painful issues involved > > in writing real-world multi-screen applications using the standard CGI > > interface (namely saving and restoring state between screens). > > The httpd on port 80 refers the browser to the newly forked http > mini-server operating on a new port. This mini-server serves only one user > and maintains state in memory from one request to the next. This is a possible solution, but it's too much of a kludge. Also it works with assumption that every user can have his own server, and those servers never talk to each other, or have good resource sharing/locking mechanism supported in application. I have already implemented session support in my HTTP server over its module protocol/API -- sessions can be kept with session keys in cookies or URL, and both "one process handles all sessions" and "every process handles his session" models are supported (process loads session policy to the server). > There are of course still authentication issues which must be dealt with on > every request. SSL or similar would be required in order to safeguard > passwords. Storing the IP associated with requests helps to avoid hijack, > but is open to spoofing attacks from anyone able to intercept packets > containing the session ID. User just has to be authenticated (if he performs administration he has to be authenticated in any case), and HTTP can do it by itself, both with encryption or without it. In no case one should use originating IP for anything in security-sensitive system, if any alternative exists. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980205233803.10973A-100000>