Incorrect Error 406 from application_top.php in some PHP configurations

[steele]

Zen cart attempts to "innoculate" parameters in the file "includes/application_top.php". One of the tests is if the length of the parameter is greater then 43 characters. Blindly doing so is a misguided attempt at checking for overly long parameters.

Current versions of PHP on some distributions now use SHA-256 by default instead of the older SHA-1 which is now considered weak. The default PHP.ini also specifies 5 bits per character for the session hash. The two settings are:

session.hash_function = sha256
session.hash_bits_per_character = 5

The old SHA-1 was 160 bits. 160 / 5 = 32 characters
The new SHA-256 is 256 bits. 256 / 5 = 51.2 characters (52 when rounded up)

In application_top.ini, if any parameter is greater than 43 characters, an HTTP 406 error is returned. This worked for the older SHA-1, but fails for the newer SHA-256 or anything longer.

NOTE: if you have a cookie from before that has zenid in it, zen-cart does not embed the zenid parameter in the page and the error will not get noticed. Clear your cookies and you experience the error.


This manifests itself in various ways:

- Existing sites can be upgraded and may appear to work. Add a second site and it breaks with error 406, even though the two sites seem identical - same host, same version of zen cart, etc.

- A site will seem to work fine, then some incident occurs - the user turns on private browsing or changes their browser settings to delete cookies when the browser is closed, the browser crashes and trashes the cookie database, etc. After this, the site mysteriously gives 406 errors, when nothing on it changed.

- The site may appear to work normally to the site owner, but new visitors complain of getting blank pages, which the site owner cannot duplicate.


The method of checking parameter length is not sustainable. As the zenid parameter grows longer the code will need to be changed, which is easy to over look, but the symptoms seem random and the source of the problems difficult to identify.

Worst case presently would be using SHA-512 with 4 bits per character which results in a zenid of 128 bits - much larger than the 43 character limit presently hard coded in application_top.php. A better method would be for the software to identify the length of the zenid parameter in use on the host and compare any incoming zenid parameter's length with that. This would scale automatically.

[wilt]

Hi,

Thanks for the bug report.

Agreed and will address in next version.