[ILUG] GET sessions...

[Fergal Daly]

At 01:57 01/06/00, adam beecher wrote:
>Anyone want to enlighten me on secure GET auth sessions? Here's my scenario:
>
>[Assume that the user has cookies turned off. Also note that I'm using my own
>custom sessions/auth libs, for picky little reasons of my own. (If you want a
>job done right...)]
>
>User comes into the site. I check to see if they have an auth session 
>(come back
>to that in a minute), and if not, I ask them to login via a form. I authorise
>them, generate a unique id and put it in the QUERY_STRING. Here's where I get
>stuck, and come back to checking - I can timeout the auth session id in 
>however
>many minutes, but as far as I can see I still have the old Hotmail 
>loophole - a
>malicious user can hijack the session using it.
>
>Now, I realise that it's unlikely, but I'm aiming for maximum security - there
>may be a packet sniffer doing his dirty deeds dirt cheap, but more likely my
>dumb user decides to send a link to his buddy, QUERY_STRING an' all. 
>Meaning the
>buddy might have access to sensitive information that the user didn't want him
>to know. Like an email to his wife arranging their illicit rendevous in a 
>seedy
>motel... :)
>
>I can't get my head around this. I *know* there's a way around it, but I just
>can't seem to figure it out. Any suggestions?
>
>Also, a query - most sites tend to use forms-based authentication - why? It
>would seem that using HTTP_AUTH, particularly with PHP ($PHP_AUTH_USER &
>$PHP_AUTH_PW available in the symbol table). Does it place extra load on the
>server or something?

If each session ID is tied to the IP addr too it will be a little more 
secure. If the timeout was short enough it would prevent the emailing a url 
problem unless the friend read his email with the same IP (ie same machine 
or happened to get the same IP from a dialin server) in just the right time 
frame. Still doesn't solve the problem of 2 people behind the same IP 
masquerading box for instance, then everyone has the same IP, back to 
square one.

Why are you insisting on GET? Wouldn't POST be more secure in terms of 
visibility of passwd/session id. All you have to do it make sure all your 
page have a hidden field which gets set to the session ID when the page is 
sent to the client. That way it's only visible in the HTML source.

I think the way around it is HTTP_AUTH or cookies. I think people tend not 
to use HTTP_AUTH as it is (or at least was) a lot less flexible. Basically 
restricted to looking up a passwd file, whereas CGI could do anything. 
These days when you can stick Perl right into Apache guts (instead of 
having to write modules in C) you can do HTTP_AUTH whatever way you like 
with ease but that sort of Apache trickery is still not widespread and so 
people just do all the auth in their CGI scripts?

When  you say that PHP can see the user and passwd is only after the user 
has actually passed Apache's auth setup?

Another possibility is that you'd have to put HTTP_AUTH on your scripts 
which means that they won't even run without a valid username and passwd, 
which doesn't allow for much in terms of feedback and doesn't let people 
use them anonymously. Also the script wouldn't get to see a cookie until 
after the user had entered username and passwd so you can't use cookies to 
allow logins that persist across browser sessions.

Fergal

P.S. Hope you can make sense of the above, I'm falling asleep!