Forum Moderators: coopster
The same problem keeps coming back to me, or "so called" problem as I don't know what the solution is.
There must be one because there's plenty of sites using sessions in the day to day running of the site. :)
So, I want a shopping cart where a session is started upon sign in and is kept valid as long as the user loads another page
For a session, only a sessionid will be registered per successful signin, which is compared to one in a mysql table for when that user logged in.
If there is a matching sessionid in the mysql table, then the user is logged in (with the respective session id).
This is all good for cookies, since the sessionid variable is kept on their local machine and is only valid for a set amount of time. AFAIK, the chances of someone spoofing a sessionid in a cookie are very small.
But when a users browser refuses to accept cookies, after a successful signin the sessionid has to be passed along in the URL.
Just as good for authentication.....the session still dies after 10 mins and the sessionid in the URL is still validated against the mysql table.
But what about my nightmare scenario that stops me finishing off this script? :)
// A user refuses cookies, signs in successfully and the appropriate sessionid is made
// The same user does his stuff on the site, sees something cool and bookmarks it, and/or pastes the URL to a friend he's chatting to
// The sessionid is still valid and the "real" user associated with it is still logged in, and the friend clicks on the link.
// The friend can see the real users shopping cart and details!
So I've read here and there, and would love to know the answer to this. Seems quite a few of the tutorials out there don't mention the fact that not all browsers accept cookies and people actually do use bookmarks.
Is the solution simply to refuse login to browsers not supporting cookies?
I hope this isn't the answer, as I'd like anyone to spend money at a site of mine. :)
Is the solution simply to refuse login to browsers not supporting cookies?
That's the way I'd go...
However, have you considered comparing IP and seesion id? Or, better still, not using the session id at all, use the username and password instead and just use sessions to register a var like $authenticated whick will read TRUE after a successful login and remain true untill they close their browser or the session length expires...
Nick
I'd like to do that, but I've read something or other about ISP's like AOL where the same user can have different IP's. It would be helpful for extra validation for sure.
>$authenticated.
OK, might be showing my ignorance here (again) ;)
If the sessionid is in the URL, and someone else loads up the page with the same sessionid, won't the username and password be associated with the sessionid? i.e. They would be seen as the "real" logged in user.
your $authenticated would only be valid for the current user. If someone else comes in with a sessionid in the url them fine, the $authenticated will read FALSE for them so you know they are not logged in ----- bring up the login form ;)
Nick
// Let's see whether sessionid is ok
$still_ok = time() - $config['session_timeout'];
$query = my_db_query("SELECT
s.username,
s.userid,
u.useremail,
u.userlevel
FROM comments_session AS s
INNER JOIN comments_user AS u
ON s.userid = u.userid
WHERE
s.sessionid = '$sessionid'
AND
(s.ip = '$REMOTE_ADDR' OR s.userid = 0)
AND
(s.lastaction >= '$still_ok' OR s.userid = 0)
AND
s.needslogin = 0");
If the session is valid...
// update last access in database
$now = time();
$query = my_db_query("UPDATE comments_session
SET lastaction=$now
WHERE sessionid='$sessionid'");
Andreas
Use the username and pass to identify, NOT the sessionid
Use the username and pass to identify when there is no or no valid session id. A session is no longer valid once it timed out.
When the session timed out, display a page for user to log in again. But you should store the data the user tried to submit or the page she tried to access. Once she logged in successfully, do whatever the user wanted to do but was prevented by the session time out. Donīt ignore the initial action the user tried to perform as so many badly designed pages do.
Andreas
I guess I've been reading off the wrong page ;)
So say I paste you a URL while im logged in...
page.php?PHPSESSID=123412341234....
So you load up the page on your browser by clicking on the link, and any validating script will recognise a username and password by association with the sessionid - that the script needs to identify the registered session as me.
If the sessionid is the same as the registered user, then how can any script tell the difference since the username and password are referenced by the sessionid? (I think this is where Im not getting it).
The IP address checking could clear that up a bit as Nick said. I've just read that checking the first 3 octets of an IP address is meant to be a good way to do it.
But still, am i getting this session/registered variables association thingy wrong or is this why I should be including IP addresses in the checkup?
What if we were both on the same network and I pasted you the URL? :)
I might just stick to cookies if I can't get my around this, or i might just be nitpicking here
here's the 'code flow' I'd recommend:
On login:
Just use the session to carry the $auth var. It's not needed for any other function on this site...
Got it? ;)
Nick
What do u meant by login by username & password?
submit username/password every page?
then, is this login?
Nick
The idea is to prevent some outsider to hijack an account. Enforcing security against your own users is a whole lot harder and in some cases next to impossible.
Andreas
So how are username and password passed from page to page to make $auth > TRUE without the sessionid coming into play in the URL?
$auth is set to TRUE if the user validates right?
So we know the suer is validated if $auth is TRUE on each page. We pass $auth using sessions.
If cookies are enabled $auth is passed as a cookie, if not it's passed in the url.
With me?
Nick
My question is the following, assuming we're using php here, what happens if php is using transparent id to pass around the SID?
Scenario: The user login, he's authorized, his browser doesn't support cookies so php reverts back to use the SID, but since it's transparent, in the browser address bar, the url looks like this: www.mydowmain.com/myproduct.php so technically, when he cuts and paste the url, does the id get compromised?
mavherick
But if I'm logged in and say to someone on messenger, "hey, check out this product" and they paste the URL (with session/auth/whatever) then how can you tell the difference.
How may I help?
But if I'm logged in and say to someone on messenger, "hey, check out this product" and they paste the URL (with session/auth/whatever) then how can you tell the difference.
I'm stumped ;)
Nick
In the end this comes down to a trade off between usability and security. Personally I wouldnīt worry too much about this telling a friend your session id. Itīs your own fault when you do. As I wrote before you donīt go around telling people your PIN or other such data. If you do thatīs your own responsibility.
Andreas
That's pretty much what I figured but, wasnøt certain...
Nick
thanks
mavherick
The problem is quite easily described. When someone else can get a valid session id then he can hijack that session and do whatever he or she wants within that session. This problems pertains to all session ids. A solution would be to check for IP addresses. This is a problem because for people behind a large proxy setup there is no guarantee that the same proxy will handle all requests from a specific user. So comparing IP addresses wonīt work. A suggested solution is to check only the first three octets or to check the x-forwarded-for header. Both arenīt fail-proof solutions.
When cookies are used then posting a URI to a forum or sending the URI to a friend wonīt jeopardize your session id which resides in the cookie. When it is in the URI, then everybody could use that session id to hijack the session identified by that is. This risk may be minimized by letting the session time out after a couple of minutes.
Andreas
thanks for your answer.
mavherick
He's right, I didn't mean to igmore you at all ;) -- just getting ready to throw a party and things are a bit hectic ;)
even when cookies are disabled, php automatically transfer it from page to page tranparently
AFAIK that's impossible. Andreas is better at this stuff than me though,,,,
Nick
thanks
mavherick
that means that the session id isn't in the address bar (even when cookies are disabled, php automatically transfer it from page to page tranparently
When cookies are disabled the session id needs to be in the URI or there will be no session id at all. Beyond cookies and URI there is no way for PHP to transparently pass along the session id.
Andreas
just getting ready to throw a party
Am I invited? With all those low fare carriers I could probably be in Denmark in about 90 minutes for just a few Euro. ;)
Have fun at your party!
Andreas
Have fun at your party!
It's a 'gluk' (glu vin) party ;) -- pj-harvey and hot spiced wine ;)
Nick
If you still post later on this evening may we expect you to sign with Hick instead of Nick again? ;)
Andreas
