Guest Posted December 29, 2005 Share Posted December 29, 2005 I just did the upgrades from 3.0.2 up to 3.0.7 and everything looks pretty good except the Print Order Form gives me a 403 error! Permissions are 644, and it is enabled. Any ideas? Thanks! Quote Link to comment Share on other sites More sharing options...
Guest ant0 Posted December 29, 2005 Share Posted December 29, 2005 I just did the upgrades from 3.0.2 up to 3.0.7 and everything looks pretty good except the Print Order Form gives me a 403 error! Permissions are 644, and it is enabled. Any ideas? I've just done 3.0.6 > 3.0.7 on one of my stores and have the same error - I think you'll also find you get 403 errors in admin when trying to look at customer orders, etc, because I am. It would seem the 3.0.7 version is a little buggy ?? :whistle: Quote Link to comment Share on other sites More sharing options...
Guest Posted December 29, 2005 Share Posted December 29, 2005 (edited) I just did the upgrades from 3.0.2 up to 3.0.7 and everything looks pretty good except the Print Order Form gives me a 403 error! Permissions are 644, and it is enabled. Any ideas? I've just done 3.0.6 > 3.0.7 on one of my stores and have the same error - I think you'll also find you get 403 errors in admin when trying to look at customer orders, etc, because I am. It would seem the 3.0.7 version is a little buggy ?? i see the error also with 777 perm. Also when i will add an order as admin i become the same error ;) Edited December 29, 2005 by charli2000 Quote Link to comment Share on other sites More sharing options...
Guest Posted December 29, 2005 Share Posted December 29, 2005 Well, I just un-did the security patch on session.inc.php and currencyVars.inc.php and have no more 403s. Give it a try. Quote Link to comment Share on other sites More sharing options...
Guest aikdo Posted December 29, 2005 Share Posted December 29, 2005 the 403 are cased by the new patch they are needed but the patch was made by myself and brooky earlier today it may still have a few small problems that can be fixed... Ill drop brooky a like when he is available and come up with the additions to the patch that will be needed... please understand all the patch was made in speed as it is a Major flaw that was found and you are ALL recomended to either update or add the patch ASAP... Quote Link to comment Share on other sites More sharing options...
Guest shawnlovebaobao Posted December 30, 2005 Share Posted December 30, 2005 the 403 are cased by the new patch they are needed but the patch was made by myself and brooky earlier today it may still have a few small problems that can be fixed... Ill drop brooky a like when he is available and come up with the additions to the patch that will be needed... please understand all the patch was made in speed as it is a Major flaw that was found and you are ALL recomended to either update or add the patch ASAP... i had the same problem with print order form Quote Link to comment Share on other sites More sharing options...
Guest airjer Posted December 30, 2005 Share Posted December 30, 2005 Same here Quote Link to comment Share on other sites More sharing options...
goober999 Posted December 30, 2005 Share Posted December 30, 2005 the 403 are cased by the new patch they are needed but the patch was made by myself and brooky earlier today it may still have a few small problems that can be fixed... Ill drop brooky a like when he is available and come up with the additions to the patch that will be needed... please understand all the patch was made in speed as it is a Major flaw that was found and you are ALL recomended to either update or add the patch ASAP... aikdo, With all due respect.... What you are saying does not make sence You found a problem, Great! You make a patch, Great! The patch does not work. Not good You insist that people apply the patch anyway? I don't get it. This release and patch are causing more harm than good. My personal opinion. /Goober :( Quote Link to comment Share on other sites More sharing options...
Guest Marshalls Posted December 30, 2005 Share Posted December 30, 2005 I have to agree this time, The 3.0.7 is giving me a biiig head ache! I have so meny more problums with 3.0.7. After 3.0.7 is more stable i think people will upgrade more and i will re upgrade again. had to downgrade due to the more problums i got. also that dam upload.php upgrade fuct me up to.. the 403 are cased by the new patch they are needed but the patch was made by myself and brooky earlier today it may still have a few small problems that can be fixed... Ill drop brooky a like when he is available and come up with the additions to the patch that will be needed... please understand all the patch was made in speed as it is a Major flaw that was found and you are ALL recomended to either update or add the patch ASAP... aikdo, With all due respect.... What you are saying does not make sence You found a problem, Great! You make a patch, Great! The patch does not work. Not good You insist that people apply the patch anyway? I don't get it. This release and patch are causing more harm than good. My personal opinion. /Goober Quote Link to comment Share on other sites More sharing options...
Guest aikdo Posted December 30, 2005 Share Posted December 30, 2005 @Goober the patched worked for is reson to stop the script kiddies in their tracks all i was saying is not to go removing it again making your store more vunrable im glad you released the edits needed and thats all i was saying is people keep the patch on while we all work out a fix... Simplicity MORE damage would have been done if the patch was left off and a Script Kiddy got to your server luckily it was such a short span from the vunrability comming out that the worse casses i heared of was peoples server s being used for SPAM... The same vunrability unpatched could have taken any server down compleatly and that would have been the hundreads maybe thousands on your server network. Quote Link to comment Share on other sites More sharing options...
Guest Posted December 30, 2005 Share Posted December 30, 2005 Look everyone the problem came about we worked out a quick patch and stopped the hackers destroying your servers. The main file you need to worry about is the order.succ.inc file all the rest are just in case jobs. i suggest you leave as is and put back these two session.inc.php and currencyVars.inc.php to back up files you made before upgrading. your store is now protected and no 403 errors. Im afraid Brooky is out of the office for a few days having a well earned break. And i dont plan on disturbing him Quote Link to comment Share on other sites More sharing options...
Guest danemist Posted December 30, 2005 Share Posted December 30, 2005 Look everyone the problem came about we worked out a quick patch and stopped the hackers destroying your servers. The main file you need to worry about is the order.succ.inc file all the rest are just in case jobs. i suggest you leave as is and put back these two session.inc.php and currencyVars.inc.php to back up files you made before upgrading. your store is now protected and no 403 errors. Im afraid Brooky is out of the office for a few days having a well earned break. And i dont plan on disturbing him Thank you for working so hard to get a fix on this. I am a very "green" newbie when it comes to things like this. I can imagine what a nightmare it is. I do have a question about this fix tho. I actually have 2 of the session.inc.php files in my storefront setup. One in /includes, one in /includes/boxes. Should I restore the backup on both of these files? The same goes for the currencyVars.inc.php . I have these files in /includes, and in /admin/includes. Again, should I restore the backup on both of these? Or just the file in /includes? I'm only getting the 403 forbidden error in admin/products/options.php and modules/gateway/Print_Order_Form/orderForm.php Thank you again for all the hard work of the folks who helped to work out the kinks on this upgrade. Quote Link to comment Share on other sites More sharing options...
Guest Posted December 30, 2005 Share Posted December 30, 2005 (edited) Go into these two files: includes/currencyVars.inc.php and includes/session.inc.php (NOT the ones under includes/boxes) and replace the line that says: if (!ereg("index.php|cart.php|download.php|switch.php|confirmed.php",$_SERVER['PHP_SELF'])) { with: if(!isset($config)) { You could replace the complete files with your backups, but I believe this is the only line that changed. That's all I did and I have no more 403 probs. Edited December 30, 2005 by jbeyler Quote Link to comment Share on other sites More sharing options...
Guest Posted December 30, 2005 Share Posted December 30, 2005 Just found this solution...might be better yet! http://www.cubecart.com/site/forums/index....ST&f=21&t=14837 where you replace it with: if (!ereg("index.php|cart.php|download.php|switch.php|confirmed.php|order.php|print.ph p|options.php",$_SERVER['PHP_SELF'])) { ...basically just adding a few more files to the list. Quote Link to comment Share on other sites More sharing options...
Guest Insurrectus Posted December 30, 2005 Share Posted December 30, 2005 (edited) Just found this solution...might be better yet! http://www.cubecart.com/site/forums/index....ST&f=21&t=14837 where you replace it with: if (!ereg("index.php|cart.php|download.php|switch.php|confirmed.php|order.php|print.ph p|options.php",$_SERVER['PHP_SELF'])) { ...basically just adding a few more files to the list. This worked great for me....'cept now postal orders don't work :w00t: Edited December 30, 2005 by Insurrectus Quote Link to comment Share on other sites More sharing options...
oldman79 Posted January 1, 2006 Share Posted January 1, 2006 Just found this solution...might be better yet! http://www.cubecart.com/site/forums/index....ST&f=21&t=14837 where you replace it with: if (!ereg("index.php|cart.php|download.php|switch.php|confirmed.php|order.php|print.ph p|options.php",$_SERVER['PHP_SELF'])) { ...basically just adding a few more files to the list. This worked great for me....'cept now postal orders don't work You need to do this code for able postal orders work, let me know if you still need help. Apply this code below in currencyVars.php, session.inc.php if (!ereg("index.php|cart.php|download.php|switch.php|confirmed.php|order.php|orderForm .php|print.php|options.php",$_SERVER['PHP_SELF'])) { Apply this code below in orderSuccess.php if (!ereg("index.php|cart.php|download.php|switch.php|confirmed.php|orderForm.php|print .php|options.php",$_SERVER['PHP_SELF'])) { It will Print Order Form out very well, and it work!!!! Quote Link to comment Share on other sites More sharing options...
Guest Insurrectus Posted January 2, 2006 Share Posted January 2, 2006 That did the trick. Thank you all. Quote Link to comment Share on other sites More sharing options...
Guest Posted January 2, 2006 Share Posted January 2, 2006 Just found this solution...might be better yet! http://www.cubecart.com/site/forums/index....ST&f=21&t=14837 where you replace it with: if (!ereg("index.php|cart.php|download.php|switch.php|confirmed.php|order.php|print.ph p|options.php",$_SERVER['PHP_SELF'])) { ...basically just adding a few more files to the list. This worked great for me....'cept now postal orders don't work Try clicking on "Product Options" after 3.0.7 upgrade. Same problem.... Forbidden 403. Any others discovered? Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted January 2, 2006 Share Posted January 2, 2006 This is probably a better solution: if (ereg(".inc.php",$HTTP_SERVER_VARS['PHP_SELF'])) { Quote Link to comment Share on other sites More sharing options...
Guest Posted January 2, 2006 Share Posted January 2, 2006 This is probably a better solution: if (ereg(".inc.php",$HTTP_SERVER_VARS['PHP_SELF'])) { That's probably a good idea in addition to something like the Sir William fix for the config variables (make 'em all constants, I say). This would keep a hacker from running any of the ".inc.php" files independently, and it won't cause the 403 errors that folks had with the original code. How about also shipping CubeCart with an .htaccess file that sets REGISTER_GLOBALS to off for good measure (I know this would only work on Apache servers, but that would cover the vast majority of web hosts). Or I guess you could do it for everyone using something like this: CubeCart could come out of this crisis as the most secure eCommerce script around...if (@ini_get('register_globals')) foreach ($_REQUEST as $key => $value) unset($GLOBALS[$key]); Quote Link to comment Share on other sites More sharing options...
Guest aikdo Posted January 2, 2006 Share Posted January 2, 2006 shipping with a .htaccess would cause major problems not just to windows servers but any server that has phpSuExc security running which stops php_flag's from being used causing 500 internal server error whenever used... other servers dont allow the use of local php.ini files and others ignore ini_set... basicaly CC has to be made to be secure on both servers with and without register_globals enabled... I personaly went through every directory on my server and made a php.ini file as that is the only option my server allows... Quote Link to comment Share on other sites More sharing options...
Guest Posted January 2, 2006 Share Posted January 2, 2006 shipping with a .htaccess would cause major problems not just to windows servers but any server that has phpSuExc security running which stops php_flag's from being used causing 500 internal server error whenever used... other servers dont allow the use of local php.ini files and others ignore ini_set... basicaly CC has to be made to be secure on both servers with and without register_globals enabled... I personaly went through every directory on my server and made a php.ini file as that is the only option my server allows... I don't know if I agree with you there, Aikdo. Other script packages ship with .htaccess files and just explain to users what to do if they have issues. For the majority of hosts running an updated Apache server on Linux or Unix this seems to be the ideal tool, so I would recommend making it available. I think that more hosts don't allow you to use your own php.ini files than don't allow local .htaccess files, but then I haven't got the metrics to verify that (it's just based on my personal experience). There are a number of ways to weld this hole shut (including unregistering all globals at the top of every script), but for a lot of us this may be the best blanket protection we can get so I'd make it available (with alternate methods for those who can't use it). Quote Link to comment Share on other sites More sharing options...
Guest Posted January 2, 2006 Share Posted January 2, 2006 Thinking more about this... Why not script turning register_globals off into the install script? That way an explanation could be given as to what works for which servers in the process, and the script can test whether it has actually worked and issue a warning if not. It seems to me that this would be a relatively straighforward addition to the install process which could be based on the permissions and install directory removal code. As brooky and others have noted, this is probably the single most important security step for CubeCart and all other PHP scripts, so I think it's worth integrating. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted January 2, 2006 Share Posted January 2, 2006 Agreed there should be a warning on install if it is on and the dangers. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.