anand_ragav Posted November 17, 2006 Share Posted November 17, 2006 When a user accesses the administrative site they are issued with the PHPSESSID session cookie. This controls the authenticated state of the user’s session and appears to be solely relied upon for authorisation checks. Once the user has successfully authenticated to the application via the administrative login page they are now authorised to access the administrative resources located on the server.Consequently, if a valid PHPSESSID cookie value was stolen it can be used to gain authenticated administrative access to the application without the user being required to supply valid authentication credentials.Can somebody provide me a solution on how to overcome this issue?ThanksRA Link to comment https://forums.phpfreaks.com/topic/27549-session-hijacking/ Share on other sites More sharing options...
Nolongerused3921 Posted January 11, 2007 Share Posted January 11, 2007 I would be interested in a solution as well. Right now I have a session with the user's IP address set, and checked every page, but this does not always work. Link to comment https://forums.phpfreaks.com/topic/27549-session-hijacking/#findComment-157971 Share on other sites More sharing options...
trq Posted January 11, 2007 Share Posted January 11, 2007 If you really need that much security, use https. Link to comment https://forums.phpfreaks.com/topic/27549-session-hijacking/#findComment-157975 Share on other sites More sharing options...
btherl Posted January 11, 2007 Share Posted January 11, 2007 Sykoi, in what situations does checking the IP address not work? When the IP address changes due to proxy servers?If someone can access your session id, they could probably have accessed your username and password the same way. Presumably using a network sniffer or by intercepting your traffic at a proxy server.Like thorpe mentioned, https will largely solve those problems. Then you only need to worry about attacks on the client and server machines. Link to comment https://forums.phpfreaks.com/topic/27549-session-hijacking/#findComment-157994 Share on other sites More sharing options...
Nolongerused3921 Posted January 11, 2007 Share Posted January 11, 2007 Actually I was mistaken, I had only set the IP address as a session variable, and after some more research of _SESSION, I think I want to store session ID in a cookie, rather than append it to the URL (This is where I had some problems, if a user pastes a link to someone else, goes to another site (Referrer log), or anything like that - this can potentially be a bad thing).Can I just use "session.use_only_cookies", or is there an easier method that can be called from inside my script rather than modifying php.iniAs for security concerns - its not a big enough deal to use https, however I would really like to remove SESSID from urls, but not risk session confusion or add too much extra time to the runtime. Link to comment https://forums.phpfreaks.com/topic/27549-session-hijacking/#findComment-158062 Share on other sites More sharing options...
magic2goodil Posted January 11, 2007 Share Posted January 11, 2007 some added things you can do are by creating your own security variables that are checked for on each page as well as by checking the browser and things like that to verify that the user is the same useralso the idea of checking for ip addresses is wise as well Link to comment https://forums.phpfreaks.com/topic/27549-session-hijacking/#findComment-158081 Share on other sites More sharing options...
egalp Posted January 11, 2007 Share Posted January 11, 2007 You might consider regenerating the session ID on page traversal, keeping the session information, using [url=http://il2.php.net/manual/en/function.session-regenerate-id.php]session_regenerate_id()[/url].That way even if a specific session ID was hijacked it would be obsolete very quickly. Link to comment https://forums.phpfreaks.com/topic/27549-session-hijacking/#findComment-158183 Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.