Post by docroesner » Wed Jan 06, 2021 3:25 am

straightlight wrote:
Tue Jan 05, 2021 11:42 am
That's intended to have an error there. The csrf_helper uses a buffer to output the token and cannot be added manually with the object without using the regex for security purposes on the catalog-end side. As explained previously, you simply need workaround the paths in the XML for all your TWIG files and, to make it easier, use the VQMod Manager to see for any errors in the paths. If you can't see any, then you need to keep playing with one block of XML modifications at a time to see where the issue might be originating from in your paths.
What I did now, I inserted the lines
$this->load->helper('csrf_helper');
csrf_start();
into catalog/controller/common/header.php
That makes the token show up in a hidden input file in all forms including those which I had modified. Even though zlib.output_compression has not yet been enabled by my host manager.
Makes me wonder if that will prevent fake account registrations.
I'll report on this. We had only about 2 fake account registrations daily since about a week while we already had 60 per day in december.

User avatar
New member

Posts

Joined
Sat Jan 21, 2012 11:17 pm


Post by straightlight » Wed Jan 06, 2021 4:34 am

docroesner wrote:
Wed Jan 06, 2021 3:25 am
straightlight wrote:
Tue Jan 05, 2021 11:42 am
That's intended to have an error there. The csrf_helper uses a buffer to output the token and cannot be added manually with the object without using the regex for security purposes on the catalog-end side. As explained previously, you simply need workaround the paths in the XML for all your TWIG files and, to make it easier, use the VQMod Manager to see for any errors in the paths. If you can't see any, then you need to keep playing with one block of XML modifications at a time to see where the issue might be originating from in your paths.
What I did now, I inserted the lines
$this->load->helper('csrf_helper');
csrf_start();
into catalog/controller/common/header.php
That makes the token show up in a hidden input file in all forms including those which I had modified. Even though zlib.output_compression has not yet been enabled by my host manager.
Makes me wonder if that will prevent fake account registrations.
I'll report on this. We had only about 2 fake account registrations daily since about a week while we already had 60 per day in december.
It will only prevent manually and from the header controller. Nowhere else. Which is why, the XML file propagates by buffer in order for all template files to capture the generated token from the helper file.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by docroesner » Thu Jan 07, 2021 10:43 am

straightlight wrote:
Wed Jan 06, 2021 4:34 am
It will only prevent manually and from the header controller. Nowhere else. Which is why, the XML file propagates by buffer in order for all template files to capture the generated token from the helper file.
Fine, straightlight, I admit I do not understand anything.
The script as installed by me does not prevent any fake registrations. That's what I see after 24 hours.
I simply don't get it what I did wrong. Anyway, life goes on, doesn't it?
I'll write a script to delete all those fake registrations through a cron job on a daily basis and that will keep our
database lean.
Thanks for your effort. I see no way to make this work.

User avatar
New member

Posts

Joined
Sat Jan 21, 2012 11:17 pm


Post by straightlight » Thu Jan 07, 2021 11:12 am

docroesner wrote:
Thu Jan 07, 2021 10:43 am
straightlight wrote:
Wed Jan 06, 2021 4:34 am
It will only prevent manually and from the header controller. Nowhere else. Which is why, the XML file propagates by buffer in order for all template files to capture the generated token from the helper file.
Fine, straightlight, I admit I do not understand anything.
The script as installed by me does not prevent any fake registrations. That's what I see after 24 hours.
I simply don't get it what I did wrong. Anyway, life goes on, doesn't it?
I'll write a script to delete all those fake registrations through a cron job on a daily basis and that will keep our
database lean.
Thanks for your effort. I see no way to make this work.
As explained on previous posts of this topic, this extension does NOT prevent any fake registrations. It simply kicks out the bots out of the HTML forms. You still need to enable the best captcha extension you may find in order for the CSRF filter not to get overflood by bots behind the forms.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by docroesner » Thu Jan 07, 2021 11:08 pm

straightlight wrote:
Thu Jan 07, 2021 11:12 am
As explained on previous posts of this topic, this extension does NOT prevent any fake registrations. It simply kicks out the bots out of the HTML forms. You still need to enable the best captcha extension you may find in order for the CSRF filter not to get overflood by bots behind the forms.
Yes, this is accomplished. I have installed reCaptcha. Is it the best? I do not know.
Of course, this is obvious, if someone calls the registration form in his browser and passes his time doing a registration without intention to ever buy a single item - this cant be prevented. This can only be deleted on a regular basis as these registrations usually have address_id=0 and of course no order attached. This is trivial.
I am sure we had lots of contact form spam submitted by bots. And that should be stopped now.
I have reinstalled the contact form in one installation to see the effects and will report on this.
I am sorry for my limited understanding of zlib and buffer and whatever you deal with.
I appreciate very much your effort to dispose a script for free!
Thank you.

User avatar
New member

Posts

Joined
Sat Jan 21, 2012 11:17 pm


Post by straightlight » Fri Jan 08, 2021 12:09 am

docroesner wrote:
Thu Jan 07, 2021 11:08 pm
straightlight wrote:
Thu Jan 07, 2021 11:12 am
As explained on previous posts of this topic, this extension does NOT prevent any fake registrations. It simply kicks out the bots out of the HTML forms. You still need to enable the best captcha extension you may find in order for the CSRF filter not to get overflood by bots behind the forms.
Yes, this is accomplished. I have installed reCaptcha. Is it the best? I do not know.
Of course, this is obvious, if someone calls the registration form in his browser and passes his time doing a registration without intention to ever buy a single item - this cant be prevented. This can only be deleted on a regular basis as these registrations usually have address_id=0 and of course no order attached. This is trivial.
I am sure we had lots of contact form spam submitted by bots. And that should be stopped now.
I have reinstalled the contact form in one installation to see the effects and will report on this.
I am sorry for my limited understanding of zlib and buffer and whatever you deal with.
I appreciate very much your effort to dispose a script for free!
Thank you.
Regarding the address_id=0, not an issue, since the csrf_helper uses a session superglobal, you could re-call that session into your browser by creating an event and use the __csrf key to avoid these sorts of activities on occurring (undocumented process though). ;)

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by docroesner » Sat Jan 09, 2021 9:47 pm

straightlight wrote:
Fri Jan 08, 2021 12:09 am
Regarding the address_id=0, not an issue, since the csrf_helper uses a session superglobal, you could re-call that session into your browser by creating an event and use the __csrf key to avoid these sorts of activities on occurring (undocumented process though). ;)
I am too stupid for these things.
I have a cronjob running once a week that deletes all customer accounts without order and address_id attached. Delets also the history and IP in the respective tables.
Also I found a characteristic of all these fake registrations that allows me to stop them in the register validation script so it doesn't even go into the database.

What remains enigmatic for me is: what is the purpose of these activities?
It seems there are people being paid for registering accounts that serve for what?

User avatar
New member

Posts

Joined
Sat Jan 21, 2012 11:17 pm


Post by straightlight » Sun Jan 10, 2021 5:36 am

It seems there are people being paid for registering accounts that serve for what?
To collect information. Welcome to the new world of Journalism!

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by ADD Creative » Sun Jan 10, 2021 8:36 am

docroesner wrote:
Sat Jan 09, 2021 9:47 pm
What remains enigmatic for me is: what is the purpose of these activities?
It seems there are people being paid for registering accounts that serve for what?
One use is the attackers use bots to register on multiple sites and therefore send out lots of registration emails to victims. The purpose if to fill up their victims mailboxes in the hope that the victim doesn't spot more important emails about more malicious activity.

www.add-creative.co.uk


Active Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by straightlight » Sun Jan 10, 2021 10:56 pm

I have a cronjob running once a week that deletes all customer accounts without order and address_id attached
The only problematic with this is that you'd also be deleting a valid customer's account which may not yet have an address; GDPR / SCA / CCPA .

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by docroesner » Tue Jan 12, 2021 9:01 am

straightlight wrote:
Sun Jan 10, 2021 10:56 pm
The only problematic with this is that you'd also be deleting a valid customer's account which may not yet have an address; GDPR / SCA / CCPA .
Of course. I checked my database for the entries of the last 10 years. And there is not a single customer registered without address_id which appears natural. That's why I consider it pretty safe to do this cronjob.
Meanwhile they managed to avoid my validation trap. Interesting, but what I have done now, I send the script to sleep for 30 minutes whenever someone enters with the new characteristic of the fake registrations.
Another observation: they use now IP addresses from France, Netherlands and Germany, instead of Russia and Ucrania. And there are no more *.ru Emailaddresses. That shows they did not know what I was filtering for. Anyway, this is a fools game, isn't it?

User avatar
New member

Posts

Joined
Sat Jan 21, 2012 11:17 pm


Post by docroesner » Tue Jan 12, 2021 9:05 am

ADD Creative wrote:
Sun Jan 10, 2021 8:36 am
One use is the attackers use bots to register on multiple sites and therefore send out lots of registration emails to victims. The purpose if to fill up their victims mailboxes in the hope that the victim doesn't spot more important emails about more malicious activity.
Then I would expect they will give up soon as bot registrations should be impossible with this CSRF code.
I have CSRF and reCaptcha at these forms. Nevertheless, some fake registrations per day. Ridiculous.
Perhaps it would be good to stop the registration confirmation email to be sent to the customer. It's enough to send an order confirmation, isn't it?

User avatar
New member

Posts

Joined
Sat Jan 21, 2012 11:17 pm


Post by straightlight » Tue Jan 12, 2021 9:59 am

docroesner wrote:
Tue Jan 12, 2021 9:01 am
straightlight wrote:
Sun Jan 10, 2021 10:56 pm
The only problematic with this is that you'd also be deleting a valid customer's account which may not yet have an address; GDPR / SCA / CCPA .
Of course. I checked my database for the entries of the last 10 years. And there is not a single customer registered without address_id which appears natural. That's why I consider it pretty safe to do this cronjob.
Meanwhile they managed to avoid my validation trap. Interesting, but what I have done now, I send the script to sleep for 30 minutes whenever someone enters with the new characteristic of the fake registrations.
Another observation: they use now IP addresses from France, Netherlands and Germany, instead of Russia and Ucrania. And there are no more *.ru Emailaddresses. That shows they did not know what I was filtering for. Anyway, this is a fools game, isn't it?
It sure is. Especially when other locations are are heading to the a store to attempt the same type of operations another location used to do.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by straightlight » Tue Jan 12, 2021 10:00 am

docroesner wrote:
Tue Jan 12, 2021 9:05 am
ADD Creative wrote:
Sun Jan 10, 2021 8:36 am
One use is the attackers use bots to register on multiple sites and therefore send out lots of registration emails to victims. The purpose if to fill up their victims mailboxes in the hope that the victim doesn't spot more important emails about more malicious activity.
Then I would expect they will give up soon as bot registrations should be impossible with this CSRF code.
I have CSRF and reCaptcha at these forms. Nevertheless, some fake registrations per day. Ridiculous.
Perhaps it would be good to stop the registration confirmation email to be sent to the customer. It's enough to send an order confirmation, isn't it?
It's also enough to flood the email limitation per day a service provider could set in order to reach its limit more rapidely.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by ADD Creative » Tue Jan 12, 2021 8:34 pm

docroesner wrote:
Tue Jan 12, 2021 9:05 am
Then I would expect they will give up soon as bot registrations should be impossible with this CSRF code.
I have CSRF and reCaptcha at these forms. Nevertheless, some fake registrations per day. Ridiculous.
Perhaps it would be good to stop the registration confirmation email to be sent to the customer. It's enough to send an order confirmation, isn't it?
The CSRF protection might not stop bots if the bot reads the form before submitting or it is not implemented correctly. It seems reCaptcha can be bypassed as well. The reCaptcha implementation in OpenCart is also flawed. https://github.com/opencart/opencart/pu ... -311109197

You could stop sending the registration confirmation. This would be helpful in preventing your site being listed as a spammer. However, it might not stop the registrations as I doubt they check the emails have actually been sent.

www.add-creative.co.uk


Active Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by straightlight » Tue Jan 12, 2021 8:39 pm

Captcha won't prevent CSRF attackers to remain parked behind HTML forms, and this, for a longer period without restriction. Which is why, this extension has been developed.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by khnaz35 » Tue Jan 12, 2021 8:52 pm

So in nut shell no matter whatever you do to prevent attacks it will still happen🤣

Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature ;) :) :-*


User avatar
Active Member
Online

Posts

Joined
Mon Aug 27, 2018 11:30 pm
Location - Malaysia

Post by straightlight » Tue Jan 12, 2021 9:26 pm

khnaz35 wrote:
Tue Jan 12, 2021 8:52 pm
So in nut shell no matter whatever you do to prevent attacks it will still happen🤣
Of course. The HTML forms will always contain bots behind the wall.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by imager » Sun Jan 17, 2021 11:54 pm

Getting ready to install on a OC 3.0.2.0 site and had a question. When editing the php.ini file, there is mention to add the line:

Code: Select all

zlib.output_compression = On
however, I saw a couple of messages that indicated the line to add was:

Code: Select all

zlib.compression_output  = On
Maybe I misunderstand, so just looking for clarification on the correct syntax.

The other question was whether the line should be terminated with a semicolon? My php.ini will end up looking like:

Code: Select all

magic_quotes_gpc = Off;
register_globals = Off;
default_charset	= UTF-8;
memory_limit = 64M;
max_execution_time = 36000;
upload_max_filesize = 999M;
safe_mode = Off;
mysql.connect_timeout = 20;
session.auto_start = Off;
session.use_only_cookies = On;
session.use_cookies = On;
session.use_trans_sid = Off;
session.cookie_httponly = On;
session.gc_maxlifetime = 3600;
allow_url_fopen = on;
zlib.output_compression = On;
Thoughts??

New member

Posts

Joined
Fri Nov 09, 2012 7:05 pm

Post by straightlight » Mon Jan 18, 2021 12:11 am

Thoughts??
Google (2001): https://www.php.net/manual/en/zlib.configuration.php .

Semi-colon: No semi-colons should be showing from any lines. See the original file version from Opencart.com when downloading OC v3.x releases.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON
Who is online

Users browsing this forum: No registered users and 3 guests