Jump to content
Our Partners

ecartz

♥Ambassador
 View Profile  See their activity

  • Content count

    3,744

  • Joined

  • Last visited

  • Days Won

    63

Posts posted by ecartz

  1. Posted

    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. 

  5. Posted

    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

  6. Posted

    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. 

  8. Posted

    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. 

  9. Posted

    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. 

  10. Posted

    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). 

    domiosc reacted to this

  14. Posted

    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. 

    ce7 reacted to this

  17. Posted 

    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. 

  18. Posted

    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. 

    Demitry reacted to this

  19. Posted

    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. 

  24. Posted

    1 hour ago, Demitry said:

    As for the INF field/attribute

    That was a division by zero.  It breaks the query but wouldn't harm the site.  It's one of the queries (there are four) starting at https://github.com/gburton/CE-Phoenix/blob/1.0.7.3/advanced_search_result.php#L178

    File injection is more likely to be caused by something that writes files.  E.g. admin/backups.php, categories.php, define_languages.php. 

    And also consider the possibility that the reason for the .mx file is that there is some software somewhere that allows the creation of a .mx file but not a .txt or .html file.  That doesn't sound like osCommerce.  It's more likely to be a vulnerability outside your site. 

    The coincidence of times may simply be that the the same bad actor attempted both attacks on your site and on the server at the same time.  You might find more clues from attempts to access files on your site that don't exist.  Perhaps one of those found another site on the same server that did have whatever vulnerability. 

×