Maintained by Steve Southwell - ses at bravepointdallas dot com

For those who may be new to web development, in general, it may come as a surprise that it is difficult to keep tabs on which user is doing what on your website. Because the web is "Stateless" in nature, each interaction between a user and your web application is stand-alone by default.

To understand the importance of keeping a session, or maintaining "pseudo-state", consider the following scenario:

• User A, an administrator, logs in to your application with username and password.
• User B, a sales rep, does the same.
• User A requests a listing of customer accounts.
• User B requests a listing of his own customer accounts.
• User A clicks one of the accounts, requesting an edit screen.
• User B does the same.
• User A hits the "Save" button, saving the record.
• User B does the same.

• The system would have to ask for username and password info on each and every hit.
• The system would not be able to distinguish between user A and user B.
• The system would not be able to recall that it had earlier displayed a list of valid customers to user B, when user B chooses a customer.

Over the years, many session management schemes have been tried, not just with WebSpeed, but with all sorts of web application engines. As it turns out, many of these schemes have stopped evolving when it was determined that they did a good job of keeping track of who is who. However, the unique security requirements of the web, require that we have a system that not only works, but will properly fail to work when they are exploited by attackers.

Various of the earlier schemes relied on such insecure methods as simply storing the user ID in a cookie, or using sequentially numbered session identifiers that are keys to a database table. Some utilized the IP address to lookup previous interactions with the user. For various reasons, all of these techniques have failed to provide for proper security of a web application.

To make matters worse, up until now, WebSpeed developers have either relied on the "State-persistent" mode of WebSpeed development, which is a HUGE mistake, or they have rolled their own solutions, often falling into the traps listed above. All of this causes development time to increase, and security to be questionable.

To truly "get it right", most grizzled web programming veterans seem to agree on the following points:

• Cookies are not to be relied upon. (Microsoft ASP fails this, and so does WebSpeed's state-persistent model)
• The concept of a "session" does not have to imply authentication as a valid user - just that a given user is the "same" user that hit us a moment ago.
• Web Sessions should be randomly numbered, in such a way that someone could not possibly guess a correct one. Microsoft, (believe it or not) handles this correctly with its ASP Session IDs.
• Web Sessions should timeout after a certain pre-defined period of inactivity. (Keeps brute-force attacks on session ID from succeeding)
• IP addresses cannot be relied upon to guarantee session uniqueness, or authenticity. These can not only be faked, but are often masqueraded or changed by various proxy and caching servers on the net. An IP address is only one indicator of authenticity, but cannot be relied upon to authoritatively verify authenticity.
• The session ID should be passed from page-to-page in both hidden fields and in ALL links back to the application.

Please also note: There are some webobjects that you can use to view and trace user session data. These are included in the webstatetools.zip file, that you must download seperately. If you use these objects, please keep in mind that you are expected to add your own security mechanism to keep the general public from being able to use them. You have been warned!

[Download webstate.zip] - 37kb
[Download webstate.tar.gz] - 34kb
[Download webstatetools.zip] - 59kb (ESS webobjects for viewing / tracing session data)
[Word Documentation] - 29kb
[PDF Documentation] - 19kb

[Return to Unreviewed Code Section]
[Return to Main Download Page]