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.docroesner wrote: ↑Tue Jan 05, 2021 11:15 am@supak111: I have downloaded this OCmod version and will try it on a test installation of OC. Many thanks!
@Straightlight:
I have asked the host manager to enable zlib.compression_output on a php level and will see if that changes anything.
I have installed now vqmod on another hosting account where OC 3.0.3.6 is installed. zlib.compression_output is enabled there.
The admin login form shows the token field perfectly.
However, no other form on the customer side shows any hidden token-field.
Since I have account/register.twig modified there, I included the lines
{% if csrf_form_input %}
{{ csrf_form_input }}
{% endif %}
in the template right below the form open tag.
That does not resolve anything (I included some text with this modification and that shows up in the source code).
So that means csfr_form_input is empty when loading the form.
Then I modified the modified catalog/controller/account/register.php in the storage folder and included the lines
$csrf = new Csrf();
$csrf->csrf_start($this->registry);
$data['csrf_form_input'] = $csrf->csrf_form_input();
in function index()
That gave a fatal error saying
Class 'Csrf' not found in /....../storage/modification/catalog/controller/account/register.php
Seems I put this code in the wrong place. Where do I have to include it?
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
I tried to install the ocmod version into a test installation of OC (Version 3.0.3.6) but received an error saying "The directory system/helper is not allowed to be written to!". Then I set the permissions from 755 to 777 for both. Same error.supak111 wrote: ↑Tue Jan 05, 2021 8:02 amYes there are only 2 files in the vQmod version of this extension. You must have vQmod installed.
BUT I converted it to OCmod so download my version below and install it vie admin: extension --> installer
VQmod version of CSRF Protection Form Extension https://www.opencart.com/index.php?rout ... on_id=4773
OCmod version download it here: https://gofile.io/d/pHognI
PS only tested on 3.0.3.2, should work on all oc 3xxx
Ideas?
What I did: I put the lines
$this->load->helper('csrf_helper');
csrf_start();
into catalog/controller/common/header.php as indicated by install.xml and that worked!
Now I see, the hidden token input in the source code.
Does that really mean, the forms are now protected? I have NOT installed the extension (due to the error given above) and have no install.xml on the server!
What I did now, I inserted the linesstraightlight wrote: ↑Tue Jan 05, 2021 11:42 amThat'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.
$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.docroesner wrote: ↑Wed Jan 06, 2021 3:25 amWhat I did now, I inserted the linesstraightlight wrote: ↑Tue Jan 05, 2021 11:42 amThat'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.
$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.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Fine, straightlight, I admit I do not understand anything.straightlight wrote: ↑Wed Jan 06, 2021 4:34 amIt 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 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.docroesner wrote: ↑Thu Jan 07, 2021 10:43 amFine, straightlight, I admit I do not understand anything.straightlight wrote: ↑Wed Jan 06, 2021 4:34 amIt 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 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.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Yes, this is accomplished. I have installed reCaptcha. Is it the best? I do not know.straightlight wrote: ↑Thu Jan 07, 2021 11:12 amAs 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.
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).docroesner wrote: ↑Thu Jan 07, 2021 11:08 pmYes, this is accomplished. I have installed reCaptcha. Is it the best? I do not know.straightlight wrote: ↑Thu Jan 07, 2021 11:12 amAs 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.
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.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
I am too stupid for these things.straightlight wrote: ↑Fri Jan 08, 2021 12:09 amRegarding 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 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?
To collect information. Welcome to the new world of Journalism!It seems there are people being paid for registering accounts that serve for what?
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
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.docroesner wrote: ↑Sat Jan 09, 2021 9:47 pmWhat 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?
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 .I have a cronjob running once a week that deletes all customer accounts without order and address_id attached
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
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.straightlight wrote: ↑Sun Jan 10, 2021 10:56 pmThe 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 .
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?
Then I would expect they will give up soon as bot registrations should be impossible with this CSRF code.ADD Creative wrote: ↑Sun Jan 10, 2021 8:36 amOne 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.
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 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.docroesner wrote: ↑Tue Jan 12, 2021 9:01 amOf 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.straightlight wrote: ↑Sun Jan 10, 2021 10:56 pmThe 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 .
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?
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
It's also enough to flood the email limitation per day a service provider could set in order to reach its limit more rapidely.docroesner wrote: ↑Tue Jan 12, 2021 9:05 amThen I would expect they will give up soon as bot registrations should be impossible with this CSRF code.ADD Creative wrote: ↑Sun Jan 10, 2021 8:36 amOne 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.
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?
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
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 ... -311109197docroesner wrote: ↑Tue Jan 12, 2021 9:05 amThen 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?
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.
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.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
So in nut shell no matter whatever you do to prevent attacks it will still happen
Got an urgent question that’s keeping you up at night? There might just be a magical inbox ready to help: khnaz35@gmail.com
Enjoy nature 
Of course. The HTML forms will always contain bots behind the wall.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Who is online
Users browsing this forum: No registered users and 12 guests
