Jump to content
thirty bees forum

Acer

Administrators
  • Posts

    364
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Acer

  1. On 12/28/2018 at 2:35 AM, led24ee said:

    Hi. This one (https://addons.prestashop.com/en/sizes-units/24128-product-combination-attribute-dimensions.html) seems to be exactly what I need. Does anyone have experience with this module ?

    Hi there @led24ee

    So I'm interested in purchasing this module and wanted to know your experience with it? 

    Did you land up going with it or did you find some free alternative? 

  2. Yeah I just found the code block as you mentioned before and did not go line specific. And ran the URL checker plus cleaner script as referenced in the articles you guys posted. 

    Thankfully my sites are clean. 

    Anyway, appreciate the posts. It's nice that there is still a TB community with fellow TBers 👍

    On 7/22/2022 at 10:02 PM, janoo said:

    ThirtyBees and PS 1.6 has this code slightly different from in PS 1.7:
    you can find it in "./config/smarty.config.inc.php"

    if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') {
        include(_PS_CLASS_DIR_.'/SmartyCacheResourceMysql.php');
        $smarty->caching_type = 'mysql';
    }

    but principle is as same as in original Prestashop files v 1.6.x and 1.7.x
    described in https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/

    I prefer to comment these lines, not remove at all, but it´s my decision only

    Thanks again.

    I'd also like to take the opportunity to thank Google Translate 😉 If it wasn't for you buddy, everything would be French for me or better, Czech. You help me make sense if it all 🙂

    • Like 1
  3. On 7/25/2022 at 9:23 AM, WBNet-Wout said:

    The PrestaShop article however mentions that the attacker is able to enable using MySQL Smarty cache storage features remotely and that is why they recommend removing those lines, so that if the attacker enables it remotely it will not actually be enabled due to lacking the code for that. Unfortunately there does not seem to be any detail on how the attacker is able to enable it remotely.

    See above

  4. 1 minute ago, wakabayashi said:

    As Petr clearly pointed out: just deactivate the mysql cache. IMO you should anyway not use it... Are you using it?

    Unfortunately security is still my weakness in coding. I understand, that there is some sql injection possibility. Prestashop seems to believe, that it happens in caching. But the fix does irritate me. There is already pSQL() in use. They just replaced it with another encrypt method. 

    From what we gathered it seemed that the attackers could somehow override the Smarty cache setting regardless, which means it doesn't matter that we have it on the correct setting. Unless I'm completely mistaken?

    So what to do here? 

  5. On 7/1/2022 at 10:18 AM, datakick said:

    That's great to hear. I have moved this to bleeding edge, will be part of 1.4.0 (to be released soon).

    Fingers crossed. 🙂

    Do we know how well this behaves on Warehouse and Panda themes incl. their bundled modules? 

  6. 2 hours ago, datakick said:

    I did a little more investigation.

    Thisbis a chained exploit. In order for this to be dangerous, you first have to have sql injection vulnerability present in your store.

    As far as we know, there is no such vulnerability in core. But there may be, of course. And any native or third party modules can have sql injection vulnerability in their code as well.

    If your store is vulnerable to sql injection it is already huge issue. Attacker can update, delete, and possibly read any data in your database. They can change passwords, delete orders, or whatnot.

    But if you have enabled mysql smarty cache, this problem is elevated to the stars. Attacker can insert data inside smarty cache table, and smarty library will evaluate this data as php code. Which means that attacker can run arbitrary php code in your store. That's fuc*ing scary 

    The fix will be quite simle. We will sign any data stored inside this table with secret that is know to php only, not stored in db. Attacker don't know the secret, so they will not be able to insert correctly signed data into the database.

    Until the fix is designed, pleas go to Performance settings and ensure you are using filesystem smarty cache implementation. Do not edit core files as suggested above, please.

     

    Thanks @datakick for the update. Please keep us posted and let us know when a patch / update has been released. 

  7. 10 minutes ago, datakick said:

    That's correct. If you migrate from 1.2, just make sure the db is migrated properly, see the first post in this thread.

    Then, you can enable multiple values for individual features, and that's all.

    Cool, thank you. So when you say enable multiple values for individual features I assume there's no switch or toggle for that? And that it happens automatically? 

  8. Hi guys 

    A while back I noticed there was talk of 'Multiple Values for a Feature' functionality (or lol, feature) finally being part of native ThirtyBees in the new version. I'm at this part of my project now and I'm still running an older version of TB  and now I wonder if I should update to the latest? And how do I enable this feature? 

    Or if I should rather still use 3rd modules to give my store this functionality? 

    I appreciate the response. Thanks 

    @datakick

  9. Thanks @toplakd 
    However, as far as I recall you keep your site as bare-bones as possible, with the absolute minimum amount of 3rd party modules - and you don't run Panda...
    I'm curious if anyone with Panda has had issues with 1.2.

    Also should I go with bleeding edge 1.3 - i.e. were there any significant bugs in 1.2 that were fixed in 1.3 or is 1.2 nice and stable with 0 issues?
    And can I run 1.1.x on PHP 7.4?

    @datakick - your 2 cents as well pls?

  10. Hi

    We've just been told by our host that they are forcing PHP 7.4...
    Is it safe to update to TB 1.2 if you're running Panda?
    Or can TB 1.1.x run on PHP 7.4 without any problems (apart from warning notices in the log)?
    We're currently running on PHP 7.3.

    Also I'm curious if anyone here has updated a production / Live site to TB 1.2 yet and if they've run into any issues?

     

  11. Thanks for this. Seems like this dispatcher override is being used...
    On a Local version of the site, after trying a few things (and bombing the site), I eventually restored the Modules folder from an old (recent enough) backup.
    An lo and behold, it could save custom values for a feature again 😕 Wtf...
    Unfortunately I can't try this shit on Live though as it's technically a different branch and its backups have this bug.

    Probably going to be one of those weird unsolved mysteries... Not ideal...

    However, does this not assist in giving a clue perhaps: ?

    I've checked the logs and it appears to be filling up with this error when I try to add a custom product feature value:

    [Tue Dec 01 12:47:23.753602 2020] [php7:warn] [pid 18120:tid 1916] [client ::1:52514] PHP Warning:  preg_match(): Compilation failed: invalid range in character class at offset 55 in C:\\xamppnew\\htdocs\\development\\testsite\\classes\\Dispatcher.php on line 936, referer: http://localhost/development/testsite/admin3419jgisg/index.php?controller=AdminProducts&id_product=119&updateproduct&conf=4&key_tab=Features&token=ddb9b6bb5c007d48060cae23004fd3ec

    This is line 936 in my Dispatcher.php
     

     if (preg_match($route['regexp'], $uri, $m)) {

    Either way, I appreciate the assistance @yaniv14

  12. 6 hours ago, datakick said:

    Works fine for me

    I've checked the logs and it appears to be filling up with this error when I try to add a custom product feature value:
     

    [Tue Dec 01 12:47:23.753602 2020] [php7:warn] [pid 18120:tid 1916] [client ::1:52514] PHP Warning:  preg_match(): Compilation failed: invalid range in character class at offset 55 in C:\\xamppnew\\htdocs\\development\\testsite\\classes\\Dispatcher.php on line 936, referer: http://localhost/development/testsite/admin3419jgisg/index.php?controller=AdminProducts&id_product=119&updateproduct&conf=4&key_tab=Features&token=ddb9b6bb5c007d48060cae23004fd3ec

    This is line 936 in my Dispatcher.php
     

     if (preg_match($route['regexp'], $uri, $m)) {

     

    This is the code I have in the Override/classes/Dispatcher.php file
     

    <?php
    class Dispatcher extends DispatcherCore
    {
        /*
        * module: sturls
        * date: 2020-07-09 07:23:13
        * version: 1.0.0
        */
        protected function __construct()
        {
            if (Module::isEnabled('sturls')) {
                $module_inst = Module::getInstanceByName('sturls');
                $this->default_routes = array_merge($module_inst->hookModuleRoutes([]), $this->default_routes);
            }
            parent::__construct();
        }
        /*
        * module: sturls
        * date: 2020-07-09 07:23:13
        * version: 1.0.0
        */
        protected function loadRoutes($id_shop = null)
        {
            if ($id_shop === null) {
                $id_shop = (int)Context::getContext()->shop->id;
            }
            parent::loadRoutes($id_shop);
            if (Module::isEnabled('sturls')) {
                $module = Module::getInstanceByName('sturls');
                $language_ids = Language::getIDs(true, $id_shop);
                foreach($language_ids as $id_lang) {
                    foreach($module->lang_field as $k => $v) {
                        $route_lang = Configuration::get($module->_prefix_st.strtoupper($k), $id_lang);
                        if ($v != $route_lang) {
                            foreach($this->default_routes as $route_id => $route) {
                                if (strpos($route['rule'], $v.'/') !== false || $route['rule'] == $v) {
                                    if ($route['rule'] == $v) {
                                        $rule = str_replace($v, $route_lang, $route['rule']);
                                    } else {
                                        $rule = str_replace($v.'/', $route_lang.'/', $route['rule']);    
                                    }
                                    
                                    $this->addRoute(
                                        $route_id, 
                                        $rule, 
                                        $route['controller'],
                                        $id_lang,
                                        $route['keywords'], 
                                        isset($route['params']) ? $route['params'] : array(),
                                        $id_shop
                                    );
                                }
                            }
                        }
                    }    
                }
            }
        }
    }


    Initially I thought that it could be the "multiple values for a feature" module that I'm using, but I've since disabled that and I'm still getting this error...

    Any ideas?

×
×
  • Create New...