Administrator
- Join Date:
- Sep 2009
- Location:
- Stuart, FL
- Posts:
- 14,100
- Plugin Contributions:
- 56
AbuseIPDB Integration module
marcopolo:
I’m exploring a possible new feature for the AbuseIPDB plugin to prevent bots from rapidly creating sessions in Zen Cart (e.g., 1000+ sessions in a short time), which can overload the server. I’ve seen this happen a few times—bots create thousands of sessions and cause major performance issues. Since Zen Cart’s session_start() in application_top.php runs before the plugin can intervene, we need to block these requests before session creation.
Goal:
Block session creation for IPs that exceed a rate threshold (e.g., 100 sessions in 1 minute), while allowing normal browsing patterns (e.g., 100 sessions over 30 minutes).Proposed Approach:
Use an auto-loader or similar method to run a check before session_start() in application_top.php.
Track session rates per IP in TABLE_ABUSEIPDB_CACHE (session count and window start time).
Use a sliding window (e.g., 60 seconds): increment count per request, reset after window expires.
If the count exceeds the threshold, return a 403 Forbidden response and exit.
Alternative (Not Preferred):
Dynamically write deny rules to .htaccess to block IPs at the Apache level before PHP runs. We’d prefer to avoid this for compatibility with non-Apache servers.This issue is rare but impactful, so we need to address it. I’d really appreciate input from anyone who’s tackled similar problems, or ideas on the cleanest and most portable way to intercept or throttle session creation before session_start() runs. Any advice on standard mechanisms, code examples, or pitfalls to watch out for would be greatly appreciated!
If there isn’t a clean way to accomplish this in the current Zen Cart architecture, I’d suggest considering it for a future version. It would be ideal if Zen Cart provided a standard pre-session hook or filtering mechanism—either in the core or through a well-documented extension point—so modules like AbuseIPDB (or others) can intercept and block abusive requests before sessions are created. This would make handling rate-limiting and abuse much more robust and portable going forward.
Thanks,
The problem, IMO, with the proposed approach is the requirement for the site's autoloading to occur as it requires database accesses to determine whether/not to shut down the request.
I realize the non-Apache risk with the alternative solution, but it's probably the best choice to shut down the unwanted accesses before additional server resources (i.e. database and file-system) are required.
For either approach, you could use an auto-loader and load your processing after breakpoint 50 (where the database connection is made and configuration settings read) and prior to breakpoint 70 (where the session is established).
