getting rid of session ids in urls - GoFuckYourself.com

campimp · 08-07-2008, 05:35 AM

I have some php pages that show nasty session ids at the end of the url.

i have tried looking through google to find a way to hide these. seen a couple solutions that used some code in .htaccess, but they did not work for me

anyone know how to get rid of them?

thanks

Skrrp · 08-13-2008, 01:06 PM

Little more info would be useful. Assuming: the session ID is a GUID that links into a record in the database/backing store to track the user as they browse the site.

Without seeing the site or source, I am making guesses here, but can you not use the $_SESSION object to store this information?

Check out my site (yeah, no graphics, but the code works). I'm using $_SESSION to store login information server side (per client). Each page that uses login details, it re-calls the login each time. This ensures that the user is 'up to date' at each point (in an account takeover war, as soon as someone changes the password, the other instance is kicked out on next page load).

If you want me to take a look, chuck me a link here or in a PM, but I will probably want to see source at some point if I can help.

Snap3 · 08-14-2008, 03:15 AM

Can't PM here :D

bbm · 08-16-2008, 07:51 AM

Try to show full code of your php page here

redwhiteandblue · 08-18-2008, 11:03 AM

Did you put these two lines in your htaccess?

php_value session.use_trans_sid 0
php_value session.use_only_cookies 1

Skrrp · 08-22-2008, 02:47 PM

Interesting suggestion that I have never come across before, but I shy away from cookies as like in the URL, the data is subject to user tampering. See the PHP manual on secure procedures.

The best I have ever seen for trusting user data was a web based game with no HTTPS connection. To send the password in the plain, he had some javascript in the HTML that MD5'd the password, then MD5'd it again with salt. If a user altered the code client side, the result would probably not match the MD5 hash the server was using, unless you have a dedicated hacker. I might consider something like this if you are going to trust a cookie.

When I say dedicated hacker, MD5 has been broken and there are ways to re-create the hash quickly. This means that if someone gets to the cookie (or is sniffing packets) and can read your source code, they can re-create the hash. The best way to avoid this is to add salt on the server, using PHP that the attacker cannot read.

You might also consider a newer, better hashing algorithm. And salt, always with the salt.

08-07-2008, 05:35 AM	#1
campimp Confirmed User Industry Role: Join Date: Jan 2007 Location: Gamehendge Posts: 1,340	getting rid of session ids in urls I have some php pages that show nasty session ids at the end of the url. i have tried looking through google to find a way to hide these. seen a couple solutions that used some code in .htaccess, but they did not work for me anyone know how to get rid of them? thanks

08-14-2008, 03:15 AM	#3
Snap3 Confirmed User Join Date: Oct 2006 Posts: 808	Can't PM here :D __________________ Don't waste money, Buy traffic that converts!

08-18-2008, 11:03 AM	#5
redwhiteandblue Bollocks Industry Role: Join Date: Jun 2007 Location: Bollocks Posts: 2,793	Did you put these two lines in your htaccess? php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 __________________ Interserver unmanaged AMD Ryzen servers from $73.00

08-13-2008, 01:06 PM	#2
Skrrp Registered User Join Date: Aug 2008 Location: Wales Posts: 5	Little more info would be useful. Assuming: the session ID is a GUID that links into a record in the database/backing store to track the user as they browse the site. Without seeing the site or source, I am making guesses here, but can you not use the $_SESSION object to store this information? Check out my site (yeah, no graphics, but the code works). I'm using $_SESSION to store login information server side (per client). Each page that uses login details, it re-calls the login each time. This ensures that the user is 'up to date' at each point (in an account takeover war, as soon as someone changes the password, the other instance is kicked out on next page load). If you want me to take a look, chuck me a link here or in a PM, but I will probably want to see source at some point if I can help.

08-16-2008, 07:51 AM	#4
bbm So Fucking Banned Join Date: Oct 2005 Posts: 3,710	Try to show full code of your php page here

08-22-2008, 02:47 PM	#6
Skrrp Registered User Join Date: Aug 2008 Location: Wales Posts: 5	Interesting suggestion that I have never come across before, but I shy away from cookies as like in the URL, the data is subject to user tampering. See the PHP manual on secure procedures. The best I have ever seen for trusting user data was a web based game with no HTTPS connection. To send the password in the plain, he had some javascript in the HTML that MD5'd the password, then MD5'd it again with salt. If a user altered the code client side, the result would probably not match the MD5 hash the server was using, unless you have a dedicated hacker. I might consider something like this if you are going to trust a cookie. When I say dedicated hacker, MD5 has been broken and there are ways to re-create the hash quickly. This means that if someone gets to the cookie (or is sniffing packets) and can read your source code, they can re-create the hash. The best way to avoid this is to add salt on the server, using PHP that the attacker cannot read. You might also consider a newer, better hashing algorithm. And salt, always with the salt.