Forum Moderators: phranque
Okay, I'm no newbie to ASP programming and the concept of maintaining user session state; I'm aware of the various options, their strengths, weaknesses and so forth.
My question is this ... in an ASP (not .net) environment, is it possible to maintain state of a user in the querystring alone, in a secure manner, particular to one user, with no way of this state 'passing hands' from one user to another simply by them exchanging copied urls?
As an extremely poor example, I could have something like this:
mypage.asp?userid=1
But obviously this invites the current user to edit the url and thus access someone elses account.
I could obfuscate the querystring a little to make this more difficult, perhaps:
mypage.asp?sessionid=87hGytrF9
And employ various encryption techniques to pretty much ensure that this could be a semi viable option, but if I were to paste this url into a forum (such as this), or email it to someone, then it would be clickable by a user other than myself and they would then have access to my session.
I did employ a technique of checking http_referer and if it was empty or was not from within the target website, it would reset the session. This worked very well, because if a user edited the url a new session would start. Clicking on a copied url from any source would start a new session also ... it was the 'perfect' solution.
Except it was also flawed: Contrary to popular belief, I found that response.redirects passed the http_referer just fine and I've been able to avoid any issues with onclick events.
However, meta-refresh does not pass the referer (and this is a requirement for 1 page in my site) and in researching possible solutons for this I found that certain internet security software packages can also block http_referer (and also possibly AOL?).
It became increasingly obvious to me that http_referer is a hit-or-miss affair, in which case relying on this for my sessionid validation is a non-starter.
I have also considered combining sessionid and someform of encrypted 'thumbprint' into one code in the url, but I'm not sure what this thumbprint should be.
If I take the users IP address, and then check that a session is paired with the correct IP, this - at face value - works, but multiple users in the same household or company can have the same address and thus they could, theoretically, steal each others sessions by just being in a position to be able to see/use their urls.
I also considered somefomr of time-related thumbprint, so the link only works for a given period of time, but this in essence becomes very similar to the Session Object and I really dislike the whole 'timeout' factor.
Plus, a valid user could walk away from his/her computer for a few minutes, come back and find hisher own URLs are no longer valid.
Is it possible to create an URL that is tied to the current user and only the current user, that if pasted into a forum or emailed to someone, would fail (or create another session/thumbprint)?
This has all boiled down to using cookies, but for the sake of discussion and education, is it worth pursuing a non-cookie/querystring based solution? Or is it simply impossible?
Or is it simply impossible?
It all comes down to how much work you want to do on the back end, vs. the payoff on the front end.
If you don't want to use a cookie, and don't want to make obvious URLs, the third option is a database. You can store session information in a database tied with a user login. Much more work, but certainly doable.
Ahhhhh, someone after my own heart ;)
I'm currently using an MS SQL database and a login is required for certain parts of the site, but I'm maintaining a 'session' the moment a user enters the site (regardless of actual landing location) and then tying this to a userid in the database once and if they log in. This works great.
The 'catch' is if I track a sessionid in the url and the user then passes this to someone else - in an email, posted link, or whatever, that other person could then take over the session *UNLESS* I can determine that it's a new user and the old sessionid is no longer valid for them.
In other words, if this was my url:
[mysite.com...]
and I posted that somewhere and you clicked on it, then my website would have to be able to tell my SID of "aCfTrGh" from your own ... I can't just request.querystring ("sid") and assume that's a valid session to be used as is.
I *was* checking the http_referer and if it was empty or another site, I'd recreate the sessionid regardless of what was in the url. This worked great ... editing the url, clicking a link in an email, or entering the site form elsewhere all initiated a new session (tracked in the database).
The problem is that I have heard that http_referer is not to be relief upon (I don't know how true this is); easily spoofed, often masked by internet security programs and possibly even AOL by default. This is disastrous, because now everypage is going to assume that it's a new user and assign a new SessionID.
But, and this is the reaosn for my post, I'm not one to give in, roll over and use other methods simply because I can't think of a method to get around this.
Tonight I think I may have come up with something viable; a sessionid fingerprinted with the user's IP (I don't care if it's masked or not), possibly with a third component that changes everypage, so by the time the link is being viewed, it has already been used and has expired ... only unclicked links will have this unexpired component.
My only concern here is that it's possible for a users IP to change while viewing the site, so theoretically I could 'loose' my validation of them. Not sure if that's a real risk or not or something to be too overly concerned about.
If you have another idea, regardless of the work involved, I'd love to hear it :)
