Someone is creating new fake customers accounts

[alphabet]

I noticed that a bot can construct a query string to ANY url with action=logn and get a server response.

It would be better if the server only responds to a form submission.

Here is some htaccess code that may prevent it:

RewriteCond %{QUERY_STRING} (?:^|&)action=logn [NC]
RewriteCond %{SERVER_NAME} !^www.YOURDOMAIN.com
RewriteRule ^.* - [F,L]

It seems to work when I made curl requests compared to through my website. I also tested HTTP_HOST.

I'm not sure if HTTP_HOST or SERVER_NAME can be spoofed but it would be easier than guessing IPs.

I'm wondering if the code could cause problems with third party modules or API requests?

[Mike521w]

alphabet, I agree about the ReCaptcha thing. I've been going back and forth with Miva support about it since Monday. They think a developer can fix it - and I should either contact a 3rd party dev or Miva's Professional Services dept. They don't think it's a bug or vulnerability with Miva itself.

For argument's sake I added ReCaptcha and CSRF to our ACAD page, then wrote up a PHP script that bypasses that and sends a post to merchant.mvc to create a new (bogus) account. Works perfectly. I assume the person who's hitting all of our sites has a script that does something similar. In my case they first requested the ACAD page, then sent a post to merchant.mvc. My script does the same thing - I parse ACAD for CSRF token / session ID etc, then post bogus data to merchant.mvc (along with the valid CSRF / session ID). I don't see how ReCaptcha can work without merchant.mvc validating its token.

Maybe a module developer can write a module that will run before merchant.mvc processes the post data, which can validate the ReCaptcha token. I haven't looked into it myself yet, but that will be my next step.

Last I sent to Miva was to ask them to explain to me how a developer can fix this - if they confirm that a 3rd party module can fix it then I'll work on it from that angle. Since they don't think it's a bug or a vulnerability, I don't think a fix is coming from their end on this.

[Bruce - PhosphorMedia]

I believe that, without modification, reCaptcha can't stop a direct URL request. You'd need something to be in between the front end and miva.

A simple component module could work. One could also add non-recaptcha tools such as velocity checking (only allowing one submission per IP for example) and honey pot types of blocking (the form includes a input value, that IF populated, blocks the action associated with it. This is because bots try to put something in every field they see. So, you have something like '<input type="checkbox" name="iAgree"> I Agree' and then hide it via CSS. If its checked, then its a bot.

[Mike521w]

Bruce - PhosphorMedia To my surprise, the person who hit our site waited a few minutes between each request. Over the course of the weekend a few hundred accounts were created - but not thousands. I guess they assumed velocity checks might be in place so they played it safe.

I'm guessing you mean that the honey pot thing would also require a component module, since a post directly to merchant.mvc would need to verify if the "iAgree" field was checked. So it looks like a module to either validate this sort of field and/or validate a ReCaptcha token is the only option...?

I've only written a couple of Miva modules and it's not what I'd consider a fun way to spend an afternoon, but looks like I know what I'm doing over the next few days :/

[Bruce - PhosphorMedia]

I think you'd probably want to use a System Module. Then, in the System Module Action function do your tests.

Here's how I'd approach it (keeping it as simple as possible):

Use SMT generated variables to control what actions will be checked. For example:

<mvt:assign name="g.CheckMePlease" value="'ICST|LOGN|NEWS"/>

So, in the System_Module_Action feature you can use:

<mvif expr="l.action IN g.CheckMePlease AND g.IAgree">
<mvassign name="g.action" value="">
</mvif>

(Not positive this will work, but worth a shot.)

[Mike521w]

Bruce - PhosphorMedia Thanks for the suggestion Bruce - I just finished a system extension module that validates Google's ReCaptcha token server-side. I didn't end up using the checkbox you mentioned, just token validation, which should be fine.

My tests show it to work so far, but I haven't written a script that emulates a browser and gets it's own (presumably low-scoring) token. But in testing against the fake-account PHP script I wrote last week, it always works - anything with a missing or invalid token fails. I'll watch over the next week or so to see if any fake accounts are created. I've still been getting a steady flow of them, so if a week goes by with none, then mission accomplished.

[wajake41]

Nevermind

[wajake41]

Nevermind

[Bruce - PhosphorMedia]

We had a similar issue on our save your basket page recently. we added a recaptcha to the form and that stopped it. As part of this, we disabled the submit button and only enabled it using a call back when the recaptha was checked. We used recaptcha2.

Most bots are not 'clicking' submit buttons. You have to block the submittal of the form post at the miva executable layer.

[wajake41]

Thanks for the clarification Bruce.
Maybe after Mike521w's solution is confirmed, he could market it. We'd be interested for possible future use if it can be assigned to any of our miva modules
needing protection from bot attacks. Just have it in the toolbox in case.

[Mike521w]

wajake41 Working so far - no fake accounts have been created since I installed it, and regular accounts are being created just fine. I did find a bug today and had to do some rewriting to fix it, so still not something I'd want to release to everyone - but maybe in a few days if all continues to go well

[wajake41]

Hi Mike:
That sounds encouraging.
Can a way to retrieve the secret key be added? Maybe from a SQL table?

[Mike521w]

Yea, the admin interface has a spot for you to enter the site key and secret key (right now it only uses Google ReCaptcha v3). Site key is not currently used but I figured if I ever update it to handle the front end, can't hurt to have a field for it. Right now this only handles the back end, so code must be added to the front end manually (google's scripts, etc).

In the Miva admin interface you enter the actions you want it to monitor (ICST in this case) and the tolerance level (Google returns a score of 0 - 1), so if you enter .4, anything less than that will be rejected (user will get a blank screen with no info whatsoever).

[bonnie1525]

I have read through this post several times, but not sure what can be done to stop the bot from creating accounts. Is there a solution? Any help would be greatly appreciated!

[lesliekirk]

Now I get to add to the list of sites that are getting spammy account creations. This one is using Levels, so there is no short form involved. I was going to ask if the Payment reCAPTCHA could be used on the ACAD which seems to be triggered using this item

<mvt:item name="payment" />

My concern is if this token is used, is it controlled by the Payment Settings? I'm assuming it is, so using it probably will not work. As someone else mentioned, can I use the code from the source code? Will that have any impact on the reCAPTCHA on the OPAY page? As in, will it get triggered? And I just thought of this, if the token is used, will it help with IP blocking? So many questions...