I’m getting session ID’s in my URLs. Presumably this is a security risk and also could be a problem for search engines. How do I go about removing these?
Turn on the SEO Addon
This has been discussed in the following threads:
[url]http://forum.cs-cart.com/showthread.php?t=11478[/url]
[url]http://forum.cs-cart.com/showthread.php?t=11444[/url]
I am not sure what has happened with this. There is a bug report in the Bug Tracker but it deals with an unsecure cookie:
[url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=954[/url]
This should probably be reported in the Bug Tracker. I think this allows more transparency by making the problem visible and also allowing us to see what progress is being made.
Bob
I am not sure how you have your cart or server configured, but I do not have any session IDs in my URL’s. I am using 2.06. I logged in as a user and ordered several products and never saw a session id in the URL. I logged out and ordered a few more products and still did not see any session IDs. It might be a setting on your server that is causing this for you and not cs-cart. Ask your host.
David
[quote name=‘Triplets’]I am not sure how you have your cart or server configured, but I do not have any session IDs in my URL’s. I am using 2.06. I logged in as a user and ordered several products and never saw a session id in the URL. I logged out and ordered a few more products and still did not see any session IDs. It might be a setting on your server that is causing this for you and not cs-cart. Ask your host.
David[/QUOTE]
Do you have SSL enabled ?
I have this problem and SSL is enabled.
[quote name=‘joe’]I have this problem and SSL is enabled.[/QUOTE]
Problem occurs only when ssl is enabled. Few weeks ago I was raising this question in support:
[QUOTE]Please let me explain.
The fact that the “sess_id” parameter appears when the redirect from HTTPS to HTTP link is performed it is a default CS-Cart behavior, it is used for saving the session data.
But unfortunately, we cannot say why some normal (not secure) pages on your site were indexed as HTTPS ones by Google.[/QUOTE]
Session information can be saved in cookie but cs-cart does not support this…
Also I would like to say that indexed pages with sess id can be punished by google. Google strongly recommends disabling such pages from crawl.
So this problem is solved or not?
[quote name=‘joe’]So this problem is solved or not?[/QUOTE]
Nope, they offered me custom development… Should someone order custom development to fix a security related bug? 
[quote name=‘Darius’]Nope, they offered me custom development… Should someone order custom development to fix a security related bug? :)[/QUOTE]
Maybe I have to look into the code…
There are 3 options for SSL:
- checkout
- admin area
- everything
Google (or anyone else) should not be crawling the admin area or performing a checkout (or add to cart). Hence you should never transition from https to http unless there is something where they are following an add to cart link.
There is/was a huge security issue with the sess_id implementation where if someone sent a link with a sess_id in the URL and you were ANY logged in user, then this link would expose all the orginator’s private information to the logged in user. I do not know if this was addressed in 2.0.6. The intent was to combine the sess_id with the IP address used when the sess_id was created if if they don’t match, to invalidate (maybe remove) the sess_id from the URL.
[quote name=‘tbirnseth’]There are 3 options for SSL:
- checkout
- admin area
- everything
Google (or anyone else) should not be crawling the admin area or performing a checkout (or add to cart). Hence you should never transition from https to http unless there is something where they are following an add to cart link.
There is/was a huge security issue with the sess_id implementation where if someone sent a link with a sess_id in the URL and you were ANY logged in user, then this link would expose all the orginator’s private information to the logged in user. I do not know if this was addressed in 2.0.6. The intent was to combine the sess_id with the IP address used when the sess_id was created if if they don’t match, to invalidate (maybe remove) the sess_id from the URL.[/QUOTE]
Session information can be saved in cookie also, but cs-cart does not currently support this. IP thing is not ready yet also… That is why I do not use ssl for now even I have it…
[quote name=‘Darius’]Session information can be saved in cookie also, but cs-cart does not currently support this. IP thing is not ready yet also… That is why I do not use ssl for now even I have it…[/QUOTE]
If SESSION data were saved in cookies then:
- it would be a big performance hit because SESSION info is processed before the page is sent to the browser. I.e. you’d have to do a full round trip from server-browser-server to get the info (SESSION can be pretty big).
- Using cookies for SESSION data kind of defeats the purpose of SESSIONS
If you really mean keeping the session id in a cookie, then yes, this is standard practice and cs-cart does in fact keep the session id in a cookie.
That’s how it knows which session id to use (to pull the data from the database). Take a look at core/class.session.php. It will get the cookie (session id) and then go to the DB to get the data associated with that SESSION. Why they use sess_id at all is beyond me, other than they are trying to preserve anonymous user carts across real SESSION boundaries. I.e. you can return to the site in a new SESSION and continue shopping.
But they also keep sess_id (their own cookie crumb) in a cookie so have no clue why they seem to want/need it in the URL.
Ok, I’ll try to explain. Session ID is passed in URL in 1 case only: you’re redirecting from http to https (or reverse). Why did we do it? In most cases domains for http and https connections differ (e.g. site.com and secure.host.com/~site.com) and cookie, set on http connection can’t be passed to https, so - you’ll loose session information.
Solution…
- It’s very simple to remove session ID from URL, e.g. (core/fn.control.php) put this code
// If URL contains session ID, remove it
if (!empty($_REQUEST[SESS_NAME]) && $_SERVER['REQUEST_METHOD'] == 'GET') {
fn_redirect(fn_query_remove(Registry::get('config.current_url'), SESS_NAME));
}
below this code
//If $config['http_host'] was different from the domain name, there was redirection to $config['http_host'] value.
if ((defined('HTTPS') ? Registry::get('config.https_host') : Registry::get('config.http_host')) != REAL_HOST && $_SERVER['REQUEST_METHOD'] == 'GET' && !defined('CONSOLE')) {
fn_redirect((defined('HTTPS') ? Registry::get('config.https_location') : Registry::get('config.http_location')) . '/' . Registry::get('config.current_url'));
}
2. Security - link session ID with IP address? Is it enough? I think not.
Any suggestions?
Works like charm! Thank you
[quote name=‘zeke’]Ok, I’ll try to explain. Session ID is passed in URL in 1 case only: you’re redirecting from http to https (or reverse). Why did we do it? In most cases domains for http and https connections differ (e.g. site.com and secure.host.com/~site.com) and cookie, set on http connection can’t be passed to https, so - you’ll loose session information.
Solution…
- It’s very simple to remove session ID from URL, e.g. (core/fn.control.php) put this code
// If URL contains session ID, remove it
if (!empty($_REQUEST[SESS_NAME]) && $_SERVER['REQUEST_METHOD'] == 'GET') {
fn_redirect(fn_query_remove(Registry::get('config.current_url'), SESS_NAME));
}
below this code
//If $config['http_host'] was different from the domain name, there was redirection to $config['http_host'] value.
if ((defined('HTTPS') ? Registry::get('config.https_host') : Registry::get('config.http_host')) != REAL_HOST && $_SERVER['REQUEST_METHOD'] == 'GET' && !defined('CONSOLE')) {
fn_redirect((defined('HTTPS') ? Registry::get('config.https_location') : Registry::get('config.http_location')) . '/' . Registry::get('config.current_url'));
}
2. Security - link session ID with IP address? Is it enough? I think not.
Any suggestions?[/QUOTE]
So are you saying that if we implement your suggestion above, our site will be less secure? Or are you talking about something else?
[quote name=‘kingsleypress’]So are you saying that if we implement your suggestion above, our site will be less secure? Or are you talking about something else?[/QUOTE]
No, no, linking session with IP address will improve the security quite the contrary. I just think that we need to link it with something else.
[quote name=‘zeke’]No, no, linking session with IP address will improve the security quite the contrary. I just think that we need to link it with something else.[/QUOTE]
So what does this
[url]http://forum.cs-cart.com/showpost.php?p=58150&postcount=13[/url]
actually do?
[quote name=‘Darius’]So what does this
[url]http://forum.cs-cart.com/showpost.php?p=58150&postcount=13[/url]
actually do?[/QUOTE]
It removes session ID from all URLs, so no one (googlebot, bad guy :), etc…) can see your session ID.
It would be good to have this as a config option for those who have SSL on their site domain.