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
>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
>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.
>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
>>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
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
allow logins that persist across browser sessions.
P.S. Hope you can make sense of the above, I'm falling asleep!
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!