yes you can change that
ini_set('session.use_trans_sid', 0); // php wont add sess_id to urls anymore
ini_set('session.use_only_cookies', 1); // php wont even accept sid's unless its from a cookie now.
you can do the above in .htaccess too so you dont need to do it in ever script
i wouldnt worry about your pages being cached. if your sending a nocache header that should take care of it
you might wanna read up on http and the cache control headers, but thats another subject.
i usually send this header
header('Cache-control: private, must-revalidate');
private means the only thing that is allowed to cache it is the browser itself, not other caches. but its possible nocache might be what you want in your particular situation. the private header is usefull when dealing w/ input forms, because internet exploder has a bug and sending the private header fixes it. thats off subject though.
it sounds like your pretty thurough checking your user input. thats good. you can still turn register globals off if you can use .htaccess though.
php_flag register_globals off
i wouldnt be too concerned about the session.cookie_lifetime(if thats what you set to 100000). that does seem kinda long though. unless you need it that long, you might wanna reduce it a bit.
i really think you were being hacked because of passing the sid through the url. stop doing that and you have eliminated that hole. now the only way they can do that is if they hijack the users cookies, which is very hard to do.
you could further beef up security by looking at session.referrer_check, but this is just icing on the cake, its not really meant to prevent hackers, its more meant to help when your passing the sid through the url, if someone posts that url on a message board. it keep everyone who clicks on the link from accidently hijacking the session, but its not fail proof. if the browser doesnt send a referrer header at all, this directive will be totally ignored and wont help. but i dont see many drawbacks to using it, just mainly benefits(even w/ cookies) so every bit helps.
you could expand upon the above concept and do a check on the browsers user_agent as well. i would NOT recomend doing that w/ the ip address though, because people have dynamic ips that sometimes change on every page. but the browser does not change, so you can safely block all session requests unless the user_agent matches the value you recorded when you first started the session. heres a simple example
session_start();
// if we have not recorded thier user_agent yet, do it
if (!isset($_SESSION['HTTP_USER_AGENT'])) {
$_SESSION['HTTP_USER_AGENT'] = $_SERVER['HTTP_USER_AGENT'];
}
// now check if the current user_agent matches the one which started the session
if ($_SESSION['HTTP_USER_AGENT'] != $_SERVER['HTTP_USER_AGENT']) {
exit; // silently, dont give the hacker any hints as to why
}
