[ILUG] GET sessions...

[adam beecher]

Fergal,

Thanks for the comprehensive reply.

> 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.
>
I thought of using the IP as a secondary check, but on top of the scenarios you
mentioned above, there also the case where people are tied to a small block of
IP addresses, and could be assigned a different one on each request. Again, it's
the exception rather than the rule, but this is for a system that *has* to be as
near as dammit to 100% secure.

> 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.
>
POST is no good in a "real" environment - people need to be able to click around
in regular links and carry their session with them. I could of course simulate
that with a hidden form and JavaScript event handlers, but that would be slow.
And it has to be 100% downwards compatible too. You've set my mind whirring
though - what about HTTP_REFERER? If the user doesn't have a HTTP_REFERER that
matches against the site itself, they're obviously coming from somewhere they
shouldn't be, so I can send them an error, right? Can you spoof HTTP_REFERER?

> 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?
>
Same goes for cookies as for JavaScript above - I'll use 'em if they're
available but I have to be downwards compatible. I'm still curious about
HTTP_AUTH though, and why people don't use it more widely. The only downside I
can see is that the user stays logged in until the browser is closed, but I've
seen Webmin (Perl) get around that, and I'm sure I can figure out how they did
it.

And as you said, it's much easier these days - it doesn't just have to be a
passwd file, or even "real" HTTP_AUTH. There's mod_perl, as you mentioned above;
mod_php; and the lesser known, greater-spotted mod_auth_mysql, written by Ralf
Engelshall (author of mod_ssl, mod_rewrite and plenty of the core Apache code).
So if it's easier, and everybody knows it's easier, why aren't people doing it?
Just because no-one else is?! :)

> When  you say that PHP can see the user and passwd is only after the user
> has actually passed Apache's auth setup?
>
No, when PHP is built as a module, it uses the auth hooks to tie directly into
Apache. It's very cool actually, you can even skip the dialog box and retrieve
the auth data from a regular form. Check it out:

http://uk.php.net/manual/html/features.http-auth.html

> 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.
>
Well, PHP HTTP_AUTH allows for that. I dunno, I seem to be left with two
options, unless anyone can come up with something else:

1) Use PHP HTTP_AUTH. Unfortunately though, this won't work with the CGI binary,
which is a problem because the app will be released, and an awful lot of people
are parked on virtual servers with CGI binaries.
2) Use HTTP_REFERER to check for valid referers. But I have this niggle at the
back of my mind that there's a loophole there I'm not seeing.

Anyway, thanks again for the reply, you've left me with some food for thought.

> P.S. Hope you can make sense of the above, I'm falling asleep!
>
No sweat. Just get up later. Pretty soon you'll be into a routine, and you won't
be *able* to sleep before four. :)

Thanks Fergal,
adam