Jump to content

ecartz

♥Ambassador
  • Content count

    3,604
  • Joined

  • Last visited

  • Days Won

    61

Posts posted by ecartz


  1. If you do not have the .htaccess file and try to open the images directory in your browser (just the directory, no file), what happens?  If it says you are not authorized, you can delete the following line from the .htaccess file

    Options -Indexes

    It is conceivable that that would fix things. 

    I suspect that your host has set some configuration that conflicts with the .htaccess file.  If your error logs don't give any more information, then they would be the ones who would have to do the next steps of debugging.  You might ask them about AllowOverride and AllowOverrideList values in httpd.conf.  E.g. in the documentation:  https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride

    Quote

    In the example above, all directives that are neither in the group AuthConfig nor Indexes cause an internal server error.

    The .htaccess file uses the Limit directives. 

    It is possible that they might have to incorporate the directives from the old version of the .htaccess file into the httpd.conf in a Directory section.  The old version because they are using Apache 2.2.  The new version should be compatible with both 2.4 and 2.2 but otherwise has no advantages over the old version. 

    I.e. the choices are either for them to configure your site

    AllowOverride Limit

    or to incorporate

    <FilesMatch "\.(php([0-9]|s)?|s?p?html|cgi|pl|exe)$">
       Order Deny,Allow
       Deny from all
    </FilesMatch>
    
    Options -Indexes

    into the httpd.conf files. 


  2. More ways to check the Apache version from PHP:  https://stackoverflow.com/questions/2927954/how-to-get-the-apache-version

    Yet more ways to check:  https://stackoverflow.com/questions/166607/how-do-i-find-the-version-of-apache-running-without-access-to-the-command-line

    If none of that works, ask your host.  They also may be able to tell you if there are restrictions on .htaccess files that would cause trouble. 


  3. Apache version? 

    The .htaccess doesn't help with file permissions.  It keeps people who upload .php files to the server from being able to run them.  It's to cover for the directory permissions being 777. 

    I'd create a test file, test.php with content

    <?php
    
    echo 'Hello world!';

    Try to visit it in the browser.  Then upload smaller versions of the .htaccess and see which makes it stop working and which makes the images stop working.  If you can find a smaller version that lets the images work while stopping the PHP file, then use that version. 

    You can see an older version of that file at https://github.com/gburton/CE-Phoenix/blob/41601da342152b010247083c1a70101aa2468d84/images/.htaccess


  4. Depending on why you want to show it, you might also put it in your conditions.  As in, Must Agree Terms & Conditions.  Messaging it from the payment module is best for letting the buyer know.  But if you simply want them to be legally advised, that's what the terms and conditions does. 

    Note that the payment module messaging dates back to

    Quote

    initial import for the osCommerce 2.x version; taken from the 2.2 MS2…

    
    … 20051113 release

    I.e. it is older than the osCommerce GitHub. 


  5. In Phoenix, the line that triggers the session_set_save_handler call is in application_top.php at

      require 'includes/functions/sessions.php';

    It seems to be claiming that output is being sent before that line.  One possibility to find what is causing it is to keep moving that line higher in the file until it either works or you get a different error.  Sometimes that helps if that line is not dependent on other code having run first.  Could not be moved prior to the includes/configure.php line.  Not sure about other dependencies. 

    It does seem like PHP 7.2 became stricter in its session handling.  So something that was always broken may now be announcing that it is broken.  Compare what you have above that line and in files included before that to what Frozen has to see what may have changed. 

    It's also worth noting that this can happen if you have a different error or warning displayed before the session started.  You can fix that by turning off display_errors.  E.g. at the top of includes/application_top.php put

    ini_set('display_errors', 0);

    Put it right before the starting time is set, after the previous comment is closed.  That may shift things from totally broken to just moderately broken.  If that is what the problem is.  So this error would go away and you could concentrate on the other problems that would still be there. 


  6. 20 minutes ago, kgtee said:

    When you make wishlist into a hook, I am curious how you ensure the wishlist action is executed before the shopping cart action. This order of execution is important as you do not want shopping cart to act first leaving nothing for the wishlist.

    Put it in the hook before the shopping cart action is processed? 

    This will be a little more complicated in 1.0.7.4, as the shopping cart actions are also processed by a hook.  But in 1.0.7.3, there is a hook call immediately prior to the processing of the shopping cart actions. 

    22 hours ago, LeeFoster said:

    The wishlist addon has its class file that contains its own count_contents function.

    Then it seems to be saying that the $wishlist object is not set.  I would probably replace it with $_SESSION['wishlist'] and it's possible that it is not triggering the wishlist creation for some reason.  Or perhaps it needs to be gated by

    if (isset($_SESSION['wishlist'])) {

    somewhere. 


  7. 1 hour ago, domiosc said:

    The hosting company say is all secure... and the vulnerable is the website...

    If you can run executable code in .ico files, that is a security hole. 

    Similarly, X-Frame-Options is generally set by Apache, not by individual applications.  https://geekflare.com/secure-apache-from-clickjacking-with-x-frame-options/

    Allowing image uploads should only be available to the admin, which should be secured by Apache's Basic Authentication (htpasswd).  Writing image files to anywhere other than images/ admin/backups and a few more locations should be blocked by directory file permissions. 

    You can disable osCommerce from allowing .ico uploads.  Look for set_extensions or I seem to recall that older versions had a default set somewhere. 

    Only the last of those is settable in application.  Some of the third is configuring for use by the application.  Some is host configuration (who owns the site files and directories; what are the permissions).  The first two are purely host configuration.  Although perhaps the .ico file is being included by something else (what?). 

    In general, clickjacking only works if you use the same browser instance to both log into your osCommerce admin and view other pages.  If you only ever use the browser instance for looking at the osCommerce admin, clickjacking won't work.  Keep one browser only for osCommerce.  This could be Chrome, Edge, Firefox, Safari, Opera, etc.  And use a different browser for regular web browsing.  Chrome and Firefox also support multiple profiles (Chrome will let you have multiple profiles open at the same time). 


  8. No, the DB update would stay the same.  The only change you'd need to make is " . TABLE_CATEGORIES . " to categories.  Otherwise , the code that you posted should be correct.  Except that it's missing the confirmation step.  You have the button and you have the code that processes the confirmation.  But I don't see the actual step for confirming the deletion. 


  9. class hook_shop_system_wishlistApp {
    
      public function listen_preActionApp() {
    // wishlist data
        if (!isset($_SESSION['wishList']) || !($_SESSION['wishList'] instanceof wishlist)) {
          $_SESSION['wishList'] = new wishlist();
        }
    
    //Wishlist actions (must be before shopping cart actions)
        if (isset($_POST['wishlist'])) {
          if (isset($_POST['products_id']) && is_numeric($_POST['products_id'])) {
            $qty = $_SESSION['wishList']->get_quantity(tep_get_uprid($_POST['products_id'], $attributes)) + (int)($_POST['qty'] ?? 1);
    
            $_SESSION['wishList']->add_wishlist($_POST['products_id'], $qty, ($_POST['id'] ?? ''));
          }
    
          if (WISHLIST_REDIRECT ==  'No') tep_redirect(tep_href_link('product_info.php', 'products_id=' . $_POST['products_id']));
          tep_redirect(tep_href_link('wishlist.php'));
        }
      }
      
    }

    Alternately, adding global $wishlist at the beginning of the function might work. 


  10. 13 minutes ago, Demitry said:

    And, the old MS2.2 site was not affected at all.

    Perhaps to lull you into a false sense of security.  Or because they didn't need it.  Corrupt the 2.2 site directly.  And use those permissions to try to corrupt the Edge site.  This works if both subdomains use the same user behind the scenes.  So corrupting the 2.2 site allows them to make changes to the Edge site.  Or almost make changes.  Perhaps they were unable to complete the hack.  Perhaps adding the .mx files was only the first step.  If they had completed the hack, you might never have known because they would have cleaned up after themselves. 


  11. You might try template_top.php and header.php.  If you don't find that text, look for what files those files include/require.  It is probably in one of those. 

    And this is exactly why we recommend upgrading from the no longer supported 2.3.4.1 Bootstrap to Phoenix.  Because if you put the same effort into upgrading as you have put into trying to make things work in the older version, this might have just worked without further intervention.  Because the Phoenix default would seem to give you the desired result.  Or if not, at least people would be able to give you more on-point advice. 

×