zen id and blank pages for first view...

Hi,

We are getting an issue with our website, when you initially visit the site, the first time you move from the home page the ZEN ID shows in the address bar and the page is blank! Reloading the page won't fix it either, you need to go back and then click the link again. It's obviously something to do with the sessions, but I'm not sure how to go about fixing it, any ideas?

I am running v1.3.6 patch 1

Thanks!

Can you post the url so people can see the problem in action.

You really need to upgrade ASAP. Your old version was released in October 2006, and has well-known security vulnerabilities.
Plus, most troubleshooting advice is geared around current versions, making it hard to assist you. Such as this one ... which points you to troubleshooting tools that are built-in since 2010 when v1.3.9 was released: http://www.zen-cart.com/content.php?124-blank-page
And hundreds of bugfixes have been included in versions released after yours.

DrByte:

You really need to upgrade ASAP. Your old version was released in October 2006, and has well-known security vulnerabilities.
Plus, most troubleshooting advice is geared around current versions, making it hard to assist you. Such as this one ... which points you to troubleshooting tools that are built-in since 2010 when v1.3.9 was released: http://www.zen-cart.com/content.php?124-blank-page
And hundreds of bugfixes have been included in versions released after yours.

I would love to but we have made WAY too many small modifications to our site, updating would simply break our site and undo everything. We will rebuild the whole site next year in any case. I'm just looking for a fix in the mean time.

It's actually not entirely a blank page but a 406 error. I noticed this while trying it in IE9 rather than Firefox.

Having hear that there are a lot of security vunerabilities, I'm not reluctant to share my URL :blush:

gabiosz:

It's actually not entirely a blank page but a 406 error. I noticed this while trying it in IE9 rather than Firefox.

406 errors are often the result of something triggering Apache's mod_security rules.
The best (only?) way to solve this is to work with you host to see exactly what it is that is triggering the error.

gabiosz:

Having hear that there are a lot of security vunerabilities, I'm not reluctant to share my URL :blush:

I assume you meant to say that you ARE reluctant to share your URL, and in this case I fully agree with you. The script kiddies do follow these forums looking for vulnerable sites that are publicly advertised as such. If you must share your URL do so in PM only. Personally I don't think it'll be of any help to us anyway.

As DrByte stated, your version is really old, which is going to make it very difficult to debug without a lot of information that isn't available to us (and some will only be available to your host).

The important thing in finding a fix though, is trying to determine what got changed to have caused to problem. You may well be using old code, but it isn't as though the code will 'wear out' - something must have changed recently in order to cause this (assumedly) recent problem. If you didn't change anything, then your host did. Ask them!

Cheers
Rod

RodG:

406 errors are often the result of something triggering Apache's mod_security rules.
The best (only?) way to solve this is to work with you host to see exactly what it is that is triggering the error.

I assume you meant to say that you ARE reluctant to share your URL, and in this case I fully agree with you. The script kiddies do follow these forums looking for vulnerable sites that are publicly advertised as such. If you must share your URL do so in PM only. Personally I don't think it'll be of any help to us anyway.

As DrByte stated, your version is really old, which is going to make it very difficult to debug without a lot of information that isn't available to us (and some will only be available to your host).

The important thing in finding a fix though, is trying to determine what got changed to have caused to problem. You may well be using old code, but it isn't as though the code will 'wear out' - something must have changed recently in order to cause this (assumedly) recent problem. If you didn't change anything, then your host did. Ask them!

Cheers
Rod

Sorry, yes, I meant that I am reluctant to share the URL knowing that there are potential issues. I'm not sure it would help in any case, as you rightly point out it seems to be an Apache/PHP thing.

It seems to have started when we added a display in stock only filter, which appends the URL with: *?stock_filter=in_stock
*, but i can't be sure, I'll have to disable this and check again.

Our site has been so heavily modified at a code level, there's just no hope of bringing it up to date at this stage.

there's just no hope of bringing it up to date at this stage.
Best to do it on your schedule versus getting hacked and being down while you then have to clean it up and then upgrade it

I hear what everyone is saying, and a new site is already in the making, in the mean time I have managed to fix this issue.

For reference, the includes/application_top.php includes a parameter check that will throw up a 406 error if the URL sting exceeds 43 characters. A bit short with more modern hash lengths, especially if you have some additional parameters appended to the URL.

On line 25 (in my version) of the includes/application_top.php, it shows ```
if (isset($_GET[$key]) && strlen($_GET[$key]) > [B]43[/B]) {

Change 43 to a more suitable higher number and the 406 error disappears for me.

Keep in mind that changing that number arbitrarily is foolish. Changing it to a SPECIFIC value for SPECIFIC reason and NO LARGER THAN ABSOLUTELY NEEDED is key. Otherwise it totally defeats the purpose of that whole section of code, which is intended to minimize abuse and improve performance even when under attack.

Thanks, it's only increased to my longest string size when the zen id is present.

gabiosz:

It seems to have started when we added a display in stock only filter, which appends the URL with: *?stock_filter=in_stock
*, but i can't be sure, I'll have to disable this and check again.

Happy to see you found a solution.

gabiosz:

Our site has been so heavily modified at a code level, there's just no hope of bringing it up to date at this stage.

This may seem a little of the wall, but have you ever considered the possibility that many of the things you have modified on this old code may actually be a standard feature of the current code?

Until you do upgrade there are still many things you can do to help protect your site: The two that I most recommend are the renaming of the admin folder (it stops most script kiddies cold), and most importantly, password protect your renamed admin folder via .htaccess. This will require that you will need two usernames/passwords to log into the admin section of your site (the .htaccess pair, and the zencart admin pair), which will be a pain for you, but makes it near impossible for a hacker to compromise the site using code injection/modification techniques).

These two simple steps should keep you safe for a while longer (indefinitely?), but you really are missing out on many other improvements made to the code over the years.. the changes haven't all be security related.

Cheers
Rod.

RodG:

Happy to see you found a solution.

This may seem a little of the wall, but have you ever considered the possibility that many of the things you have modified on this old code may actually be a standard feature of the current code?

Until you do upgrade there are still many things you can do to help protect your site: The two that I most recommend are the renaming of the admin folder (it stops most script kiddies cold), and most importantly, password protect your renamed admin folder via .htaccess. This will require that you will need two usernames/passwords to log into the admin section of your site (the .htaccess pair, and the zencart admin pair), which will be a pain for you, but makes it near impossible for a hacker to compromise the site using code injection/modification techniques).

These two simple steps should keep you safe for a while longer (indefinitely?), but you really are missing out on many other improvements made to the code over the years.. the changes haven't all be security related.

Cheers
Rod.

Hi Rod,

Thanks for the tips, we actaully manually applied all the security updates very recently, and we run a pretty tight ship as far as .htaccess files and alternate admin folder names are concerned, as well as using SSL to administer everything, so I'm not too worried. We will move to an updated site as soon as the christmas/new year sales are out of the way.

Thanks again!

gabiosz:

Hi Rod,

Thanks for the tips, we actaully manually applied all the security updates very recently, and we run a pretty tight ship as far as .htaccess files and alternate admin folder names are concerned, as well as using SSL to administer everything, so I'm not too worried. We will move to an updated site as soon as the christmas/new year sales are out of the way.

Thanks again!

Note: When I said 'you should be safe for a while longer', I was referring specifically to the currently known hacks. You actually have bigger things you may wish to worry about.

What a lot of people are finding these days isn't so much their sites getting hacked by running this old code, but moreso the fact that it is incompatible with with the current versions of PHP, so what we a seeing on an almost daily basis are merchants waking up one morning to find thier store no longer works because the server software has had an upgrade. This can be almost as catastrophic as being hacked, and some stores never recover.

Just like a hack though, this problem can occur anytime and usually without any warning.

You'll only be 'safe' from this issue if you have full control over the server software.

Cheers
Rod