Someone is creating new fake customers accounts

[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 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 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]

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.

[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?

[alphabet]

How does reCaptcha provide server side validation with the LOGN action?

I added reCaptcha to a LOGN form that enables the submit button

Once submitted, the reCaptcha response token should also be sent along to the LOGN action to be validated server-side.

The LOGN action should make a call to google's reCaptcha API to validate the token. Otherwise the LOGN will validate without an authorized domain request.

It seems to me that we would need a LOGN extension if we want to use reCaptcha.

- - - -

The CSRF token will work in most cases. There are more sophisticated bots that can brute force their way past a CSRF token in which case you would need the reCaptcha. In either case, the token needs to be validated server side.

Even if you you can validate the reCaptcha token it only prevents the server response, not the bot request. You will need a combination of IP, user-agent or ASN rule to block the bot altogether. And as Bruce pointed out, that is a game of Wackamole.

[Mike521w]

No way to remove the link since presumably they have a script that's just sending a POST directly to merchant.mvc.. I contacted Miva to see if they can add ReCaptcha

[Bruce - PhosphorMedia]

IP blocking alone is a game of Wackamole. either removing the link and using other methods of account creation or recaptcha is the only thing to stop it.

[Mike521w]

Add one more site to the list.. Looking into blocking by IP, but obviously recaptcha would be best.

[Bruce - PhosphorMedia]

A perhaps more robust implementation would be to have the reCapture populate and hidden field (or better yet, have it REMOVE a value from a hidden field). This will help when a Bot is not submitting the form directly, but rather just directly posting the form and its data to the server.

[wajake41]

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.

[GDesigns]

*Puts on tinfoil hat* I feel like someone is targeting the forums signatures with urls, as both alphabet and InvincibleRecordings have their website in the signature

No, don't think so, we had other clients with this issue. But maybe they are finally targeting Miva sites, which has been rare in the past.

[Beefy Nugget]

*Puts on tinfoil hat* I feel like someone is targeting the forums signatures with urls, as both alphabet and InvincibleRecordings have their website in the signature

[alphabet]

So now I'm getting hit. I came in this morning to about 5K bot spam. From the server logs:

52.186.121.92 - - [18/Oct/2019:03:33:57 -0400] "POST /customer-account.html HTTP/1.0" 200 40141 "https://www.alphabetsigns.com/customer-create.html" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36"
52.186.121.92 - - [18/Oct/2019:03:33:57 -0400] "GET /mm5/merchant.mvc?Screen=%3bn%3aexpression(netsparker(9))%2f*&OAuth_Provider_Code=GOOGLE&action=OAUTH_LOGIN&Store_Code=XX&Session_Id=78bfd19b6009837711d3bea0fb63e40d HTTP/1.0" 404 41182 "https://www.alphabetsigns.com/customer-account.html" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36"

I'm not sure if netsparker is the bot or why its crawling my site. I don't subscribe to their service.

I added to .htaccess:

RewriteCond %{REMOTE_ADDR} ^52\.186\.121\.92
RewriteRule ^.* - [F,L]

It's gone for now. I hope it doesn't come back.

[lesliekirk]

somehow between bruce installing the phosphor media easy account and some additional bot block code the problem has gone away.

yaay!!!