Bots attacking our OPAY page to validate credit cards

[wajake41]

It appears that our order numbers are being used by a bot or process to attempt to validate credit card numbers. This evening I noticed that about 500 order numbers have been used without any orders being placed. Is there a way during OPAY page creation to save a unique numeric number (the lower portion of a time stamp for instance) using a new table in the database keyed by basket ID. This number would be saved in the OPAY page HTML as a hidden field. This hidden field could be disguised by an element name like user ID . When page OPAY is submitted, the value in this field would be compared to the value saved in the new table with the basket ID as the key. If the number in the submitted page matches the value in the new table the row would be deleted (it has only a one time use) and the transaction would proceed through payment processing and on to INVC. It no match is made the transaction will be deleted.

Might something like this work to defer these credit card validation bots?

This would operate kind of like Miva's own version of Captcha.

Thanks,

Larry

[wajake41]

Another idea. Maybe during OPAY creation the basket id is stored as a row in the table. Then on submission of OPAY the row with the basket ID is looked for. If it's there delete the matching row and continue the checkout,
If the row is not found then cancel OPAY transaction.
No need for a hidden field this way

[Nick]

wajake41 Are the bots actually trying to run the CC's? If so the reCAPTCHA v3 module will solve that issue.

If they are just creating orders in Miva and not completing them you could add the ADPR action to the reCAPTCHA v3 module and it will prevent bots from adding items to the basket and creating orders.

[ILoveHostasaurus]

Hi Larry, the situation you've described should already be accounted for by the unique checkout session ID. So, the entity doing this has likely already customized their script for your site to hit the appropriate page where it can retrieve the uniquely generated checkout session, and then places that data into the subsequent request. Adding a new field with a random value would likely just be analyzed and accounted for during that same setup process the bad actor is going through.

The recaptcha module should help, as it can be pretty non-intrusive for legit shoppers, but requires a real browser to be involved. Similarly, if the site is not already on Cloudflare, we can work with you to get it on Cloudflare with appropriate bad bot mitigation features activated, which can greatly cut down on this type of activity. Our support group can help with that, there's no charge for the service in most use cases.

[wajake41]

Hi David: I know more about this now. The orders are being entered manually through checkout. It's not a bot on OPAY. A group of about 50 baskets were recently entered by one of the individuals. The timestamp on the basket page showed the time between them being 20 to 40 seconds. They are testing credit cards against our authorization. One order was successful (valid credit card) but we recognized it was bogus from the name and address info so we cancelled it. That order contains an ip address of 173.0.9.70. I hope Miva can block that address. We are asking Miva to look for more of these orders by the shipfname which is repeatedly used so maybe the ip address of the other individual can be determined and blocked. By the timing between basket and the repeated use of the same name and address info I think only 2 individuals are involved. This is not bothering us that much except it is running up our TaxJar cost.

[wajake41]

Hello forum: As a way to eliminate future attacks on our site like this I would like to add the customer's ip address to the basket table. This would allow us to easily block this type of action. There is a column on the basket table labeled ship_data. None of our baskets on the Basket table have information in this column. Would it be safe to store the customer's ip address in this column?
Does Miva template code have a function to retrieve the ip address of a customer?

Cheers,
larry

[wajake41]

Question: If I populate miva global field: g.basket:ship_data on the OCST page, will the Basket table ship_data column be updated with the value in this global variable when page OCST is submitted?

Thanks

[alphabet]

Would it be safe to store the customer's ip address in this column?

No.

There are many modules that interact with the ship_data field that can cause unintended consequences.

Here is code to add at the very top of the page to block an IP. But you may be playing whack-a-mole.

<mvt:assign name="g.remote_addr" value="s.remote_addr" />
<mvt:if expr="(g.remote_addr EQ '173.0.9.70') ">
<mvt:assign name="g.ok" value="miva_output_header('status', 'HTTP/1.1 403 Forbidden')" />
<mvt:assign name="l.void" value="miva_output_flush()" />
<mvt:exit>
</mvt:if>

The reCaptcha module solves this known issue. You should also look at David's advice for Cloudflare.

[wajake41]

Hello Alpha: Since these orders are being entered manually through our checkout I don't see how captcha would prevent their entry. Am I missing something. Also our site is Miva legacy so we would need to use captcha V2 we have been told. We don't want our customers suffering with captcha!
In my personal experience, captcha will keep me from using a site unless they are giving away free $100 bills ;)
Our invoice has the customer's ip address, so when they eventually found a valid credit card and created an invoice, that invoice gave us their ip address. That is how we determined the source of this action. We've used the admin blacklist to stop this for now.
I would like to have the ip address on every basket for future use for when this happens again.
Cheers, Larry

[alphabet]

You can use the basket custom fields to write to the BasketInfo table

<mvt:assign name="g.remote_addr" value="s.remote_addr" />
<mvt:item name="customfields" param="Write_Basket( 'ip_address', g.remote_addr )" />

Make sure the customfields item is assigned to the page. If you are using deferred baskets then you won't have access to the basket until the BASK page

[wajake41]

Thanks alpha: I have created an order custom field. I really want it to be a basket custom field. Are they the same? I would want to save the ip address on OCST. Will this code work there?
If I want to know the ip address that was saved for a basket how do I read this custom field when I use the Miva dashboard? Is it logically associated with it's basket table row?
I see a CFM_Order table but no CFM_Basket table. I need to retain the ip address associated with the basket, not the order, because the basket will usually never become an order.

Looking at the CFM tables now:
Conclusion: My comments above are irelavent (sp)
I see that the CFM_OrderValue table is keyed by order number not basket ID so I don't think this will work for us, we need a custom basket field.
I really want a table for the ip address keyed by basket_id.
Any ideas?

Thanks

[wajake41]

Hello Alpha Oops, I overlooked your reference to the basket info table. Just took a look at it. Will investigate.

[wajake41]

I would like to use the toolkit file_read_write function to save my ip address in a flat file. Can't find documentation for it though.
Can anyone help?
Thanks

[wajake41]

OK Alpha. I used the instructions and code you provided and the ip address is in the info column on basketInfo. You are the man!!

[nottheusual1]

Hope this helps.

57. Use export to write variables to a flat file in the "export" directory under your store's data directory. It will not write to other directories. For example:
<mvt:item name="toolkit" param="export|cust.dat^tab^customer:login,customer :ship_lname,remote_addr" />
will append the customer's login, last name and IP address to a flat file called cust.dat with the tab character as a delimiter. Other delimiters can be , or #. You can add a delete parameter to the end if you want to delete the export file so it only has the new entry in it. The delete parameter is a 1, e.g.
<mvt:item name="toolkit" param="export|cust.dat^tab^customer:login,customer :ship_lname,remote_addr^1" />