Signup abuse detection and blocking

Signup abuse detection and blocking [Paid] 1.16.11

No permission to buy ($45.00)
I'm seeing a lot of legitimate users using Cloudflare... I'm sure people can abuse it, but there are a lot using it legitimately. Maybe their WARP add-on is going through it? Not sure... but I would definitely be careful blocking it outright.
No, we're highly confident in blocking it -- the number of issues far outweigh any legit users that could be blocked. But there again, we have stricter rules than most sites, I'm only interjecting the information for the person having the issue with Cloudflare scoring.
 
  • Like
Reactions: Xon
This addon only blocks by "ISP' (well ASN) on registration, they can still login/use the site normally.

Most VPN usage (cloudflare or apple relay are not exempt) tend to full of abuse, so blocking it on registration prevents a lot of abuse.
 
  • Like
Reactions: ENF
This addon only blocks by "ISP' (well ASN) on registration, they can still login/use the site normally.

Most VPN usage (cloudflare or apple relay are not exempt) tend to full of abuse, so blocking it on registration prevents a lot of abuse.
I believe anyone using this (which is apparently, a lot of legitimate users for us) is being flagged.

 
0. Unknown browser language: tr in NL

I have score set to +1, but does not work. Only once per detection, also disabled this but no difference.
 
When this Add-on ins installed URLs like https://www.domain.tld/index.php?register/connected-accounts/facebook&setup=1 are redirected to https://www.domain.tld/login/register/connected-accounts/?setup=1 which then generates a 404.
@Xon
This is really giving us some headache:
In some cases we are redirecting to register/connected-accounts/<providerid>/?setup=1 via query parameter xfRedirect after login in some cases.
As such URLs are rewritten to login/register/connected-accounts/?setup=1 this does not work any longer as (additionally to the canonical redirect breaking the URL) getDynamicRedirectIfNot detects this a notUrl.

Can this be fixed?
While the register URLs are written under login/register, the original setup code is called and this does work with XF's connected accounts/oauth feature. This behavior is required due to cookie paths and legacy support.

I'ld need more information such as if any other 3rd party addons are touching the registration process. Opening a ticket on my add-on site is always to more reliable way for these sorts of complex technical support requests.
 
  • Like
Reactions: ENF
I'ld need more information such as if any other 3rd party addons are touching the registration process. Opening a ticket on my add-on site is always to more reliable way for these sorts of complex technical support requests.
I've opened a support ticket, but it doesn't contain much more information than I already gave here as it happens on a vanilla installation with just Signup Abuse & Standard Library installed.
 
how i can block users with vpn ?
This is a daunting task, some of the accounts created with VPN's are blocked with default settings in this addon, but that's a small percentage. It can be done, but there's no one simple way to do it. You'll have to watch people come in with VPN's and then block the ASN, but unless you block it elsewhere (server OS or application layer), they can still register with a normal ISP and then switch to a VPN. There's no 100% way to do it in an automated fashion without blocking legit users in some circumstances.

These companies that run VPN's just rent VPS's or infrastructure from other companies. So, it's a spiderweb of nonsense if you start doing this on a very granular level.
 
Can someone please advise what is meant by “shared email link” as the sole triggered detection method? Cannot see this explained anywhere and it’s just come up for the first time.
 
Can someone please advise what is meant by “shared email link” as the sole triggered detection method? Cannot see this explained anywhere and it’s just come up for the first time.
User A clicked User B's password reset or email confirmation link. It is a very strong signal that User A and User B share the same email account
 
User A clicked User B's password reset or email confirmation link. It is a very strong signal that User A and User B share the same email account
Thank you, that makes perfect sense. ls there a way to find out which way round it was? For example if it says "UserA has 1 multiple accounts" would this mean that UserA clicked whilst logged in to an account called UserB, or is it the other way round?
 
Thank you, that makes perfect sense. ls there a way to find out which way round it was? For example if it says "UserA has 1 multiple accounts" would this mean that UserA clicked whilst logged in to an account called UserB, or is it the other way round?
I'm not actually 100% sure, I'll need to check!
 
Xon updated Signup abuse detection and blocking with a new update entry:

1.16.1 - Feature & XF2.3 update

  • php 8.4+ compatibility
  • XF2.3 compatibility
  • Rename permission "View reportings" to "View multiple account reports"
  • Fix csv import/export of allowed email domains didn't work
  • Fix viewing anti-spam options page did not highlight the anti-spam options sidebar as active
  • Fix shared email link detection did not also check for shared IP usage between the affected users
  • Fix multi-account detection would fail to log events if "Multi-account report user" was invalid
  • Fix...

Read the rest of this update entry...
 
@Xon Server error log in allowed-email-domains page.

Code:
LogicException: Entity SV\SignupAbuseBlocking:AllowEmailDomainController (class: SV\SignupAbuseBlocking\Entity\AllowEmailDomainController) could not be found src/XF/Mvc/Entity/Manager.php:54

Generated by: Nirjonmela Jul 12, 2024 at 3:04 AM

Stack trace

#0 src/XF/Mvc/Entity/Manager.php(71): XF\Mvc\Entity\Manager->getEntityClassName('SV\\SignupAbuseB...')
#1 src/addons/SV/SignupAbuseBlocking/Admin/Controller/AbstractAllowOrBan.php(404): XF\Mvc\Entity\Manager->getEntityStructure('SV\\SignupAbuseB...')
#2 src/addons/SV/SignupAbuseBlocking/Admin/Controller/AbstractAllowOrBan.php(112): SV\SignupAbuseBlocking\Admin\Controller\AbstractAllowOrBan->getStructure()
#3 src/addons/SV/SignupAbuseBlocking/Admin/Controller/AbstractAllowOrBan.php(210): SV\SignupAbuseBlocking\Admin\Controller\AbstractAllowOrBan->getFilterInput('')
#4 src/XF/Mvc/Dispatcher.php(362): SV\SignupAbuseBlocking\Admin\Controller\AbstractAllowOrBan->actionIndex(Object(XF\Mvc\ParameterBag))
#5 src/XF/Mvc/Dispatcher.php(264): XF\Mvc\Dispatcher->dispatchClass('SV\\SignupAbuseB...', 'Index', Object(XF\Mvc\RouteMatch), Object(SV\SignupAbuseBlocking\Admin\Controller\AllowEmailDomain), NULL)
#6 src/XF/Mvc/Dispatcher.php(121): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(SV\SignupAbuseBlocking\Admin\Controller\AllowEmailDomain), NULL)
#7 src/XF/Mvc/Dispatcher.php(63): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#8 src/XF/App.php(2777): XF\Mvc\Dispatcher->run()
#9 src/XF.php(798): XF\App->run()
#10 admin.php(15): XF::runApp('XF\\Admin\\App')
#11 {main}

Request state

array(4) {
  ["url"] => string(40) "/admin.php?banning/allowed-email-domains"
  ["referrer"] => string(62) "/admin.php?banning/allowed-email-domains"
  ["_GET"] => array(1) {
    ["banning/allowed-email-domains"] => string(0) ""
  }
  ["_POST"] => array(0) {
  }
}
 
This latest update 1.16.2 has this option selected by default, causing errors in ACP for people without a license
Use MaxMind GeoLite2 - ASN
Requires a license key to be added to the "MaxMind GeoIP License Key" option
 
Back
Top Bottom