Post by nightwing » Tue Feb 02, 2021 10:40 am

Did you check the post prior to me posting the xml?
straightlight wrote:
Tue Feb 02, 2021 10:31 am
That XML file above is not my part of my extension.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Tue Feb 02, 2021 11:09 am

nightwing wrote:
Tue Feb 02, 2021 10:40 am
Did you check the post prior to me posting the xml?
straightlight wrote:
Tue Feb 02, 2021 10:31 am
That XML file above is not my part of my extension.
I missed your previous post before the XML attachment. It would seem that this CSRF library does not protect against JS attacks but only CSRF with PHP on the backend. I will see what I can do to integrate CSRF protection from JS attempts on the next release.

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 nightwing » Tue Feb 02, 2021 11:15 am

straightlight, thanks for checking, we will await the next release.
straightlight wrote:
Tue Feb 02, 2021 11:09 am
nightwing wrote:
Tue Feb 02, 2021 10:40 am
Did you check the post prior to me posting the xml?
straightlight wrote:
Tue Feb 02, 2021 10:31 am
That XML file above is not my part of my extension.
I missed your previous post before the XML attachment. It would seem that this CSRF library does not protect against JS attacks but only CSRF with PHP on the backend. I will see what I can do to integrate CSRF protection from JS attempts on the next release.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Tue Feb 02, 2021 11:53 am

nightwing wrote:
Tue Feb 02, 2021 11:15 am
straightlight, thanks for checking, we will await the next release.
straightlight wrote:
Tue Feb 02, 2021 11:09 am
nightwing wrote:
Tue Feb 02, 2021 10:40 am
Did you check the post prior to me posting the xml?

I missed your previous post before the XML attachment. It would seem that this CSRF library does not protect against JS attacks but only CSRF with PHP on the backend. I will see what I can do to integrate CSRF protection from JS attempts on the next release.
The problem with the XML version you posted is the <form line may differ from priority of elements between custom themes while the CSRF Helper tracks for any types of element ordering at this time. The search lines from your XML file would need to use regex to disregard the order.

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 nightwing » Tue Feb 02, 2021 1:40 pm

Hey straightlight - Yes I know this is a problem, thats why I prefer your version, it makes things way more easier. I did test using the regex you used in the previous vqmod version, however, it replaced the <form> tag instead of adding the line below so I dropped it. - Its not only difficult with the twig files but controllers too, seeing that some files may not have the same exact lines of code. For example protected function Validate and private function Validate

Code: Select all

  <file path="catalog/view/theme/*/template/account/*.twig" error="skip">
          <operation>
              <search regex="true"><![CDATA[~(<form[^>]*method\s*=\s*["\']post["\'][^>]*>)~i]]></search>
              <add position="after"><![CDATA[
                <input type="hidden" name="csrf_token" value="{{ csrf_token }}" id="input-csrf-token" class="form-control" />
                ]]></add>
          </operation>
  </file>
straightlight wrote:
Tue Feb 02, 2021 11:53 am
nightwing wrote:
Tue Feb 02, 2021 11:15 am
straightlight, thanks for checking, we will await the next release.
straightlight wrote:
Tue Feb 02, 2021 11:09 am


I missed your previous post before the XML attachment. It would seem that this CSRF library does not protect against JS attacks but only CSRF with PHP on the backend. I will see what I can do to integrate CSRF protection from JS attempts on the next release.
The problem with the XML version you posted is the <form line may differ from priority of elements between custom themes while the CSRF Helper tracks for any types of element ordering at this time. The search lines from your XML file would need to use regex to disregard the order.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Tue Feb 02, 2021 8:19 pm

nightwing wrote:
Tue Feb 02, 2021 1:40 pm
Hey straightlight - Yes I know this is a problem, thats why I prefer your version, it makes things way more easier. I did test using the regex you used in the previous vqmod version, however, it replaced the <form> tag instead of adding the line below so I dropped it. - Its not only difficult with the twig files but controllers too, seeing that some files may not have the same exact lines of code. For example protected function Validate and private function Validate

Code: Select all

  <file path="catalog/view/theme/*/template/account/*.twig" error="skip">
          <operation>
              <search regex="true"><![CDATA[~(<form[^>]*method\s*=\s*["\']post["\'][^>]*>)~i]]></search>
              <add position="after"><![CDATA[
                <input type="hidden" name="csrf_token" value="{{ csrf_token }}" id="input-csrf-token" class="form-control" />
                ]]></add>
          </operation>
  </file>
straightlight wrote:
Tue Feb 02, 2021 11:53 am
nightwing wrote:
Tue Feb 02, 2021 11:15 am
straightlight, thanks for checking, we will await the next release.

The problem with the XML version you posted is the <form line may differ from priority of elements between custom themes while the CSRF Helper tracks for any types of element ordering at this time. The search lines from your XML file would need to use regex to disregard the order.
However, the problem going backward with XML is where users don't understand the concept of troubleshooting and the change that needs to be made due to server-specific tracking as opposed to others. Secondly, due to the abolition of OCMod on the master branch, that doesn't really help on those ends. Events for this case? Loads by priority which means 50% of the modified buffered files could contain the tokens but the other half won't contain them. Loading extension/extension routes is the opposite direction; regroups the same tokens regardless of the extensions being loaded dynamically. It looks like this issue is getting bigger than simply changing the token from the browser...

Loading Captcha to simplify everything? As long as a user doesn't help CSRF attackers to successfully authenticate where bots could remain behind the forms without kicking them, that would only reduce to 1 / 10 but won't resolve the whole situation unfortunately. Payment anti-fraud extensions via service providers? That will only help for sometime until service providers suspends the merchants' accounts due to high level of fraudulent activity attempts during checkout. Store owners from the admin to feel as the only need to create the order for the customers constantly? Pointless to own a store as a last resort since CSRF attackers can still invade posted forms regardless of the APIs and IP address lookups.

Cloudflare? It could but slows down websites as hell.

Which is why, we need a more solid solution.

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 nightwing » Tue Feb 02, 2021 8:45 pm

Hi Straightlight - Well said

1) Yes I agree that ocmod is not the way to go and we should use events to deploy this mod.

2) Cloudflare? It could but slows down websites as hell - I have to object here, I use Cloudflare and my website loads in ~ 1 second. You have to configure your cloudflare account for optimal performance, i.e. enabling Rocket Loader, Caching, uploading compressed images to your store, minifying Javacript and CSS Files. You can also allow Cloudflare to rate limit visitors and show challenges for bot/attacker like traffic.

3) Payment anti-fraud extensions via service providers? - What I have done is to temporarily limit the number of countries that can access my website, I don't provide services to every country, so I only allow the countries that we work with + Bots like Google and Freshping etc using the Cloudflare Firewall - This reduces the overall access to my website, until I have a more robust solution in place. This may affect bounce rate and is entirely up to you, however I believe that sometimes you have to take a step back to take a step forward.

4) I utilize Mod_Evasive, Mod_Security, CSF Firewall and ClamAV this way I can identify and block suspicious requests, and perform two Virus Scans Daily, one 6 AM and the other 6PM.

5) I use Recaptcha on my forms and encourage users to enable TFA.

6) I also implement strict security headers etc

7) I would encourage Store Owners who are getting many spam/fake checkout attempts to switch to Bank Transfer or any modern day offline payment method, obviously the attacker will never send you a dime, but this way you don't risk getting blocked by your Card Processor, and you don't accept customer Financial Information on your website - And only real customers will send you money.

8. As it relates to CSRF - I agree that we need to work together to better this mod as best as we can

9) Maybe we can incorporate two step in all state changing requests, for example, sending a confirmation email where customers are required to open a link to approve changes like Account Information Update, Password Update, Checkout, among other things, ultimately allowing the customers to control what changes are made on their account.

Finally I will say yes, its tough owning an online store as bad actors are out there trying to destroy your business not caring if this is how you eat. But I have tried becoming my own Police as it relates to my website, and I encourage all Store Owners to do the same, pay attention to everything.
straightlight wrote:
Tue Feb 02, 2021 8:19 pm
nightwing wrote:
Tue Feb 02, 2021 1:40 pm
Hey straightlight - Yes I know this is a problem, thats why I prefer your version, it makes things way more easier. I did test using the regex you used in the previous vqmod version, however, it replaced the <form> tag instead of adding the line below so I dropped it. - Its not only difficult with the twig files but controllers too, seeing that some files may not have the same exact lines of code. For example protected function Validate and private function Validate

Code: Select all

  <file path="catalog/view/theme/*/template/account/*.twig" error="skip">
          <operation>
              <search regex="true"><![CDATA[~(<form[^>]*method\s*=\s*["\']post["\'][^>]*>)~i]]></search>
              <add position="after"><![CDATA[
                <input type="hidden" name="csrf_token" value="{{ csrf_token }}" id="input-csrf-token" class="form-control" />
                ]]></add>
          </operation>
  </file>
straightlight wrote:
Tue Feb 02, 2021 11:53 am


The problem with the XML version you posted is the <form line may differ from priority of elements between custom themes while the CSRF Helper tracks for any types of element ordering at this time. The search lines from your XML file would need to use regex to disregard the order.
However, the problem going backward with XML is where users don't understand the concept of troubleshooting and the change that needs to be made due to server-specific tracking as opposed to others. Secondly, due to the abolition of OCMod on the master branch, that doesn't really help on those ends. Events for this case? Loads by priority which means 50% of the modified buffered files could contain the tokens but the other half won't contain them. Loading extension/extension routes is the opposite direction; regroups the same tokens regardless of the extensions being loaded dynamically. It looks like this issue is getting bigger than simply changing the token from the browser...

Loading Captcha to simplify everything? As long as a user doesn't help CSRF attackers to successfully authenticate where bots could remain behind the forms without kicking them, that would only reduce to 1 / 10 but won't resolve the whole situation unfortunately. Payment anti-fraud extensions via service providers? That will only help for sometime until service providers suspends the merchants' accounts due to high level of fraudulent activity attempts during checkout. Store owners from the admin to feel as the only need to create the order for the customers constantly? Pointless to own a store as a last resort since CSRF attackers can still invade posted forms regardless of the APIs and IP address lookups.

Cloudflare? It could but slows down websites as hell.

Which is why, we need a more solid solution.
Last edited by nightwing on Tue Feb 02, 2021 9:14 pm, edited 3 times in total.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Tue Feb 02, 2021 9:09 pm

nightwing wrote:
Tue Feb 02, 2021 8:45 pm
Hi Straightlight - Well said

1) Yes I agree that ocmod is not the way to go and we should use events to deploy this mod.

2) Cloudflare? It could but slows down websites as hell - I have to object here, I use Cloudflare and my website loads in ~ 1 second. You have to configure your cloudflare account for optimal performance, i.e. enabling Rocket Loader, Caching, uploading compressed images to your store, minifying Javacript and CSS Files. You can also allow Cloudflare to rate limit visitors and show challenges for bot/attacker like traffic.

3) Payment anti-fraud extensions via service providers? - What I have done is to temporarily limit the number of countries that can access my website, I don't provide services to every country, so I only allow the countries that we work with + Bots like Google and Freshping etc using the Cloudflare Firewall - This reduces the overall access to my website, until I have a more robust solution in place. (This may affect bounce rate)

4) I utilize Mod_Evasive, Mod_Security, CSF Firewall and ClamAV this way I can identify and block suspicious requests, and perform two Virus Scans Daily, one 6 PM and the other 6AM.

I use Recaptcha on my forms and encourage users to enable TFA.

5) I also implement strict security headers etc

6) As it relates to CSRF - I agree that we need to work together to better this mod as best as we can

Finally I will say yes, its tough owning an online store as bad actors are out there trying to destroy your business not caring if this is how you eat. But I have tried becoming my own Police as it relates to my website, and I encourage all Store Owners to do the same, pay attention to everything.
straightlight wrote:
Tue Feb 02, 2021 8:19 pm
nightwing wrote:
Tue Feb 02, 2021 1:40 pm
Hey straightlight - Yes I know this is a problem, thats why I prefer your version, it makes things way more easier. I did test using the regex you used in the previous vqmod version, however, it replaced the <form> tag instead of adding the line below so I dropped it. - Its not only difficult with the twig files but controllers too, seeing that some files may not have the same exact lines of code. For example protected function Validate and private function Validate

Code: Select all

  <file path="catalog/view/theme/*/template/account/*.twig" error="skip">
          <operation>
              <search regex="true"><![CDATA[~(<form[^>]*method\s*=\s*["\']post["\'][^>]*>)~i]]></search>
              <add position="after"><![CDATA[
                <input type="hidden" name="csrf_token" value="{{ csrf_token }}" id="input-csrf-token" class="form-control" />
                ]]></add>
          </operation>
  </file>
However, the problem going backward with XML is where users don't understand the concept of troubleshooting and the change that needs to be made due to server-specific tracking as opposed to others. Secondly, due to the abolition of OCMod on the master branch, that doesn't really help on those ends. Events for this case? Loads by priority which means 50% of the modified buffered files could contain the tokens but the other half won't contain them. Loading extension/extension routes is the opposite direction; regroups the same tokens regardless of the extensions being loaded dynamically. It looks like this issue is getting bigger than simply changing the token from the browser...

Loading Captcha to simplify everything? As long as a user doesn't help CSRF attackers to successfully authenticate where bots could remain behind the forms without kicking them, that would only reduce to 1 / 10 but won't resolve the whole situation unfortunately. Payment anti-fraud extensions via service providers? That will only help for sometime until service providers suspends the merchants' accounts due to high level of fraudulent activity attempts during checkout. Store owners from the admin to feel as the only need to create the order for the customers constantly? Pointless to own a store as a last resort since CSRF attackers can still invade posted forms regardless of the APIs and IP address lookups.

Cloudflare? It could but slows down websites as hell.

Which is why, we need a more solid solution.
1) As mentioned on the above, not even Events could be helpful against CSRF since only half ways (if not less) could carry the tokens versus other extensions that won't.

2) I'll have to dig more about this performant option of Cloudflare. The more performant it is, the less features one could have but I have to make sure on that one.

3) Not enough since CSRF attackers can also originate from countries where you may or may have not filtered. That still won't prevent them to stay behind the forms.

4) These protections can be good but not once the packets gets out of your network. These are only good for internal IPs; not external ones since they mostly monitor IGMP attacks.

Recaptcha still carrys the 1 / 10 times where a valid user could encourage CSRF attackers to get in unintentionally.

5) Strict security headers is local on your domain, not for external services.

6) Becoming your own police is not enough. Which is why, crossed-site communications must be carried out in order to ensure the flexibility of e-commerce websites.

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 nightwing » Tue Feb 02, 2021 9:17 pm

Noted, I updated the post I made, take a look at point 9.
straightlight wrote:
Tue Feb 02, 2021 9:09 pm
nightwing wrote:
Tue Feb 02, 2021 8:45 pm
Hi Straightlight - Well said

1) Yes I agree that ocmod is not the way to go and we should use events to deploy this mod.

2) Cloudflare? It could but slows down websites as hell - I have to object here, I use Cloudflare and my website loads in ~ 1 second. You have to configure your cloudflare account for optimal performance, i.e. enabling Rocket Loader, Caching, uploading compressed images to your store, minifying Javacript and CSS Files. You can also allow Cloudflare to rate limit visitors and show challenges for bot/attacker like traffic.

3) Payment anti-fraud extensions via service providers? - What I have done is to temporarily limit the number of countries that can access my website, I don't provide services to every country, so I only allow the countries that we work with + Bots like Google and Freshping etc using the Cloudflare Firewall - This reduces the overall access to my website, until I have a more robust solution in place. (This may affect bounce rate)

4) I utilize Mod_Evasive, Mod_Security, CSF Firewall and ClamAV this way I can identify and block suspicious requests, and perform two Virus Scans Daily, one 6 PM and the other 6AM.

I use Recaptcha on my forms and encourage users to enable TFA.

5) I also implement strict security headers etc

6) As it relates to CSRF - I agree that we need to work together to better this mod as best as we can

Finally I will say yes, its tough owning an online store as bad actors are out there trying to destroy your business not caring if this is how you eat. But I have tried becoming my own Police as it relates to my website, and I encourage all Store Owners to do the same, pay attention to everything.
straightlight wrote:
Tue Feb 02, 2021 8:19 pm


However, the problem going backward with XML is where users don't understand the concept of troubleshooting and the change that needs to be made due to server-specific tracking as opposed to others. Secondly, due to the abolition of OCMod on the master branch, that doesn't really help on those ends. Events for this case? Loads by priority which means 50% of the modified buffered files could contain the tokens but the other half won't contain them. Loading extension/extension routes is the opposite direction; regroups the same tokens regardless of the extensions being loaded dynamically. It looks like this issue is getting bigger than simply changing the token from the browser...

Loading Captcha to simplify everything? As long as a user doesn't help CSRF attackers to successfully authenticate where bots could remain behind the forms without kicking them, that would only reduce to 1 / 10 but won't resolve the whole situation unfortunately. Payment anti-fraud extensions via service providers? That will only help for sometime until service providers suspends the merchants' accounts due to high level of fraudulent activity attempts during checkout. Store owners from the admin to feel as the only need to create the order for the customers constantly? Pointless to own a store as a last resort since CSRF attackers can still invade posted forms regardless of the APIs and IP address lookups.

Cloudflare? It could but slows down websites as hell.

Which is why, we need a more solid solution.
1) As mentioned on the above, not even Events could be helpful against CSRF since only half ways (if not less) could carry the tokens versus other extensions that won't.

2) I'll have to dig more about this performant option of Cloudflare. The more performant it is, the less features one could have but I have to make sure on that one.

3) Not enough since CSRF attackers can also originate from countries where you may or may have not filtered. That still won't prevent them to stay behind the forms.

4) These protections can be good but not once the packets gets out of your network. These are only good for internal IPs; not external ones since they mostly monitor IGMP attacks.

Recaptcha still carrys the 1 / 10 times where a valid user could encourage CSRF attackers to get in unintentionally.

5) Strict security headers is local on your domain, not for external services.

6) Becoming your own police is not enough. Which is why, crossed-site communications must be carried out in order to ensure the flexibility of e-commerce websites.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Tue Feb 02, 2021 9:33 pm

nightwing wrote:
Tue Feb 02, 2021 9:17 pm
Noted, I updated the post I made, take a look at point 9.
straightlight wrote:
Tue Feb 02, 2021 9:09 pm
nightwing wrote:
Tue Feb 02, 2021 8:45 pm
Hi Straightlight - Well said

1) Yes I agree that ocmod is not the way to go and we should use events to deploy this mod.

2) Cloudflare? It could but slows down websites as hell - I have to object here, I use Cloudflare and my website loads in ~ 1 second. You have to configure your cloudflare account for optimal performance, i.e. enabling Rocket Loader, Caching, uploading compressed images to your store, minifying Javacript and CSS Files. You can also allow Cloudflare to rate limit visitors and show challenges for bot/attacker like traffic.

3) Payment anti-fraud extensions via service providers? - What I have done is to temporarily limit the number of countries that can access my website, I don't provide services to every country, so I only allow the countries that we work with + Bots like Google and Freshping etc using the Cloudflare Firewall - This reduces the overall access to my website, until I have a more robust solution in place. (This may affect bounce rate)

4) I utilize Mod_Evasive, Mod_Security, CSF Firewall and ClamAV this way I can identify and block suspicious requests, and perform two Virus Scans Daily, one 6 PM and the other 6AM.

I use Recaptcha on my forms and encourage users to enable TFA.

5) I also implement strict security headers etc

6) As it relates to CSRF - I agree that we need to work together to better this mod as best as we can

Finally I will say yes, its tough owning an online store as bad actors are out there trying to destroy your business not caring if this is how you eat. But I have tried becoming my own Police as it relates to my website, and I encourage all Store Owners to do the same, pay attention to everything.

1) As mentioned on the above, not even Events could be helpful against CSRF since only half ways (if not less) could carry the tokens versus other extensions that won't.

2) I'll have to dig more about this performant option of Cloudflare. The more performant it is, the less features one could have but I have to make sure on that one.

3) Not enough since CSRF attackers can also originate from countries where you may or may have not filtered. That still won't prevent them to stay behind the forms.

4) These protections can be good but not once the packets gets out of your network. These are only good for internal IPs; not external ones since they mostly monitor IGMP attacks.

Recaptcha still carrys the 1 / 10 times where a valid user could encourage CSRF attackers to get in unintentionally.

5) Strict security headers is local on your domain, not for external services.

6) Becoming your own police is not enough. Which is why, crossed-site communications must be carried out in order to ensure the flexibility of e-commerce websites.
What it suggests at 9) (first paragraph) is to send an email confirmation. However, as explained on the above, this still won't prevent CSRF attackers to successfully gather the information from web forms upon successfully lookups by valid users. Using tokenization through GET from URL rather than POST from web forms still won't prevent background activities from crossed-site scripts to remain parked behind the forms with POST forms. Emails can only allow GET methods rather than POST methods which means it won't really lead anywhere on that end.

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 nightwing » Tue Feb 02, 2021 9:36 pm

I understand. Well, I will keep thinking of various ideas to help, for now we can keep what we have and improve it as we go along. Thanks
straightlight wrote:
Tue Feb 02, 2021 9:33 pm
nightwing wrote:
Tue Feb 02, 2021 9:17 pm
Noted, I updated the post I made, take a look at point 9.
straightlight wrote:
Tue Feb 02, 2021 9:09 pm


1) As mentioned on the above, not even Events could be helpful against CSRF since only half ways (if not less) could carry the tokens versus other extensions that won't.

2) I'll have to dig more about this performant option of Cloudflare. The more performant it is, the less features one could have but I have to make sure on that one.

3) Not enough since CSRF attackers can also originate from countries where you may or may have not filtered. That still won't prevent them to stay behind the forms.

4) These protections can be good but not once the packets gets out of your network. These are only good for internal IPs; not external ones since they mostly monitor IGMP attacks.

Recaptcha still carrys the 1 / 10 times where a valid user could encourage CSRF attackers to get in unintentionally.

5) Strict security headers is local on your domain, not for external services.

6) Becoming your own police is not enough. Which is why, crossed-site communications must be carried out in order to ensure the flexibility of e-commerce websites.
What it suggests at 9) (first paragraph) is to send an email confirmation. However, as explained on the above, this still won't prevent CSRF attackers to successfully gather the information from web forms upon successfully lookups by valid users. Using tokenization through GET from URL rather than POST from web forms still won't prevent background activities from crossed-site scripts to remain parked behind the forms with POST forms. Emails can only allow GET methods rather than POST methods which means it won't really lead anywhere on that end.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Tue Feb 02, 2021 9:41 pm

nightwing wrote:
Tue Feb 02, 2021 9:36 pm
I understand. Well, I will keep thinking of various ideas to help, for now we can keep what we have and improve it as we go along. Thanks
straightlight wrote:
Tue Feb 02, 2021 9:33 pm
nightwing wrote:
Tue Feb 02, 2021 9:17 pm
Noted, I updated the post I made, take a look at point 9.

What it suggests at 9) (first paragraph) is to send an email confirmation. However, as explained on the above, this still won't prevent CSRF attackers to successfully gather the information from web forms upon successfully lookups by valid users. Using tokenization through GET from URL rather than POST from web forms still won't prevent background activities from crossed-site scripts to remain parked behind the forms with POST forms. Emails can only allow GET methods rather than POST methods which means it won't really lead anywhere on that end.
Cloudflare with the latest image random captcha might help store owners to hold a while longer but won't prevent the 1 out of 10 issues still. It will only reduce the risks and impact levels between their domain and their service providers but will end up on the same result in the end with their merchant's account unfortunately.

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 nightwing » Tue Feb 02, 2021 10:19 pm

Gotcha, well again, they can actually switch to Fruadslab Pro or other third-party providers that could filter these transactions, sending less to the Merchant Gateway as well.
straightlight wrote:
Tue Feb 02, 2021 9:41 pm
nightwing wrote:
Tue Feb 02, 2021 9:36 pm
I understand. Well, I will keep thinking of various ideas to help, for now we can keep what we have and improve it as we go along. Thanks
straightlight wrote:
Tue Feb 02, 2021 9:33 pm


What it suggests at 9) (first paragraph) is to send an email confirmation. However, as explained on the above, this still won't prevent CSRF attackers to successfully gather the information from web forms upon successfully lookups by valid users. Using tokenization through GET from URL rather than POST from web forms still won't prevent background activities from crossed-site scripts to remain parked behind the forms with POST forms. Emails can only allow GET methods rather than POST methods which means it won't really lead anywhere on that end.
Cloudflare with the latest image random captcha might help store owners to hold a while longer but won't prevent the 1 out of 10 issues still. It will only reduce the risks and impact levels between their domain and their service providers but will end up on the same result in the end with their merchant's account unfortunately.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Tue Feb 02, 2021 10:24 pm

In case of future request about moving the token, that won't do it either: https://github.com/opencart/opencart/is ... -768230545 .

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 nightwing » Tue Feb 02, 2021 10:37 pm

Why not use something similar on the front end?
straightlight wrote:
Tue Feb 02, 2021 10:24 pm
In case of future request about moving the token, that won't do it either: https://github.com/opencart/opencart/is ... -768230545 .

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Wed Feb 03, 2021 12:28 am

nightwing wrote:
Tue Feb 02, 2021 10:37 pm
Why not use something similar on the front end?
straightlight wrote:
Tue Feb 02, 2021 10:24 pm
In case of future request about moving the token, that won't do it either: https://github.com/opencart/opencart/is ... -768230545 .
Because of JS tokens where 3rd party scripts can already use.

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 nightwing » Wed Feb 03, 2021 5:22 am

Ok straightlight - Question though, what would cause the regex to replace the form tag instead of adding after?
straightlight wrote:
Wed Feb 03, 2021 12:28 am
nightwing wrote:
Tue Feb 02, 2021 10:37 pm
Why not use something similar on the front end?
straightlight wrote:
Tue Feb 02, 2021 10:24 pm
In case of future request about moving the token, that won't do it either: https://github.com/opencart/opencart/is ... -768230545 .
Because of JS tokens where 3rd party scripts can already use.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Wed Feb 03, 2021 7:46 am

nightwing wrote:
Wed Feb 03, 2021 5:22 am
Ok straightlight - Question though, what would cause the regex to replace the form tag instead of adding after?
straightlight wrote:
Wed Feb 03, 2021 12:28 am
nightwing wrote:
Tue Feb 02, 2021 10:37 pm
Why not use something similar on the front end?

Because of JS tokens where 3rd party scripts can already use.
As explained on the above, it would be the ordering priority entered by the user when using the element names on the <form line.

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 nightwing » Wed Feb 03, 2021 8:22 am

I get you... Hmm that cannot be used then as I see tags with <form method and <form action... If this is what you mean
straightlight wrote:
Wed Feb 03, 2021 7:46 am
nightwing wrote:
Wed Feb 03, 2021 5:22 am
Ok straightlight - Question though, what would cause the regex to replace the form tag instead of adding after?
straightlight wrote:
Wed Feb 03, 2021 12:28 am


Because of JS tokens where 3rd party scripts can already use.
As explained on the above, it would be the ordering priority entered by the user when using the element names on the <form line.

Regards,
Nightwing
Access to my Free Extensions: https://www.opencart.com/index.php?rout ... =nightwing


Active Member

Posts

Joined
Tue Nov 05, 2019 11:08 pm


Post by straightlight » Wed Feb 03, 2021 8:32 am

nightwing wrote:
Wed Feb 03, 2021 8:22 am
I get you... Hmm that cannot be used then as I see tags with <form method and <form action... If this is what you mean
straightlight wrote:
Wed Feb 03, 2021 7:46 am
nightwing wrote:
Wed Feb 03, 2021 5:22 am
Ok straightlight - Question though, what would cause the regex to replace the form tag instead of adding after?

As explained on the above, it would be the ordering priority entered by the user when using the element names on the <form line.
They both can and must be used to import the CSRF token but the only difference is the way they're being entered by the user as priority for each element names which is why the use of regex is eminent in this case.

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 6 guests