By: Kurt Seifried, [email protected], Copyright Kurt Seifried, 2001
Because HTTP and HTTPS are stateless protocols, the server has no idea if you rebooted your computer and continued browsing, got shunted through a different proxy server, and so on. Keeping track of users is very difficult, using IP addresses does not work since a users IP may change during the session, or many users may come from one IP (i.e. AOL has large proxy servers). Most tracking methods involve handing back the user a unique piece of data, this can take the form of a cookie, URL or hidden form field to name a few. One important thing to remember is that users can (and will) modify the data you give to them, URL's and cookies are trivial to edit, HTML pages can be created with modified HTML. There have been in fact numerous security holes related to programmers implicitly trusting the data the user hands back to them. Do not do this.
The "best" method is to create a unique token for each session (i.e. a hash of the time, date, remote user IP, whatever), and encrypt the data (i.e. take the resulting hash and then use 3DES to encrypt it with a secret) it is almost impossible for an attacker to recreate someone else's token and possibly "hijack" their session or otherwise gain unauthorized access. If you use a hash of the data you will need to keep a copy locally with the time, since any timestamp will be reduced to a random series of letters. Using a timestamp alone is not safe since an attacker can simply make a copy of it and use it, you should also use identifying data such as IP address (not always reliable) browser type, and so on (basically an internal state table, a database backend can be used of course to store this data). If you know when it was issued, you can include usage rules (token expires after 10 minutes of non use, every time they use it that gets reset, or whatever), and you simply request the token each time they access the site. Users also cannot modify the token without "breaking" it if it is securely encrypted, nor can they glean what exactly it is you are handing them.
6.1 Cookies
Cookies, as mentioned in section 5.1, can be used to store unique pieces of information on a users computer. It is trivial to edit cookies, i.e. go into C:\Windows\Cookies\ with notepad and edit them. Additionally many users do not allow permanent cookies, or use cookie management software to periodically delete them. However using session cookies is relatively safe, although modifying them client side is of course possible, but the advantage is that most web browsers allow them and they are "invisible" to users.
6.2 Unique URLs
Unique URL's, as mentioned in section 5.4, can be used to uniquely identify sessions. It is extremely trivial for an attacker to modify the URL, also these URL's can "leak", to proxy servers and so on. They should only be used with extreme caution.
6.3 Hidden form fields and other HTML code
Hidden form fields and other HTML code, as mentioned in section 5.6, can be used to uniquely identify sessions. It is relatively easy for an attacker to find the HTML (i.e. view source) and edit the data contained within it, so do not use things like "admin=yes" (don't laugh, one popular CGI did do this).