Time access restriction with php

Question

I want to develop a security system, which serves both for contact form and login, the intention is that it is an additional to the use of CAPTCHA, or in some cases a substitute. The logic is as follows:

The user can access at most 4 times during intervals of 7 seconds, if he access more than 4 times that given data sending page within 7 seconds, the system understands as a bot and redirects the user to another location to "divert" traffic or performs another security measure.

This was the experimental code I developed with some friends.

OBS 1: I am not an expert in PHP, I am always in constant learning, so tips and methodologies are always welcome.

OBS 2: The idea is to redirect bots to avoid sending spam or even attacks like Brut force, then it is a Generic code for use in several cases

<?php
// Detecta BOT
session_start();
$maxTempoLim = 7; //Tempo Limite
$maxVezesLim = 4; //Numero de Vezes possiveis dentro do tempo limite

if ( ! isset($_SESSION['temp_bot'])) {
    $_SESSION['temp_bot'] = time();
    $_SESSION['conta_vezbot'] = 1;
}

$diferenTime = time() - $_SESSION['temp_bot'];

if ($diferenTime <= $maxTempoLim) {
    $_SESSION['conta_vezbot']++;
    if ($_SESSION['conta_vezbot'] > $maxVezesLim) {
        session_destroy();
        header('Location: spam_detectado.php'); //redireciona
        // ou colocar outra ação ao invés de redirecionar
        exit;
    }
} 

The idea arose from a situation where they tried to send spam to a contact form on my page and from some customers, both I added a CAPTCHA and it worked very well, only I didn’t want to force the user to type the CAPTCHA, would like to create something that detects that is a bot or any other type of system accessing uninterruptedly, and through the amount of access per second, or for a period of time that for an ordinary user would be impossible, redirect traffic.

Answer 1

I’m sorry, but this is gonna be more of a foot shot than a security measure.

Spam zombies are end-user computers that have been compromised by malicious code in general, such as worms, bots, viruses and Trojan horses. These malicious codes, once installed, allow spammers to use the machine to send spam, without the user’s knowledge. While they use compromised machines to perform their activities, they make it difficult to identify the origin of spam and authors as well. Spam zombies are greatly exploited by spammers for providing the anonymity that protects them so much. Source

Much SPAM is sent by infected computers and users do not even know. Your form can be accessed:

1. By several different machines at the same time
2. By the same machine at different times

---

If your idea is to try to prevent sending, these two cases above would be out of your logic.

I don’t think this is the way to avoid SPAM. A possible solution would be to validate the user-agent and check the incidence of shipments by that machine, along with the sender data, and the message itself.

But they will be 'measures' that will not guarantee that all blocks will be SPAM or that sent are legitimate.

If your form only allows sending by registered and identified users, login itself becomes an ANTI-SPAM prevention.

---

Updating

I’m afraid it’s best to do individual security for each case. For a type attack Brut force, you can do some layers of security and validation:

1. After X attempts between a period of X minutes, you can include captcha code
2. You can ask for additional account information, such as registered birth date or other information
3. Check how many accounts the same machine is trying to access
4. You can create an algorithm to compare the similarity of the registered password with the password used in the login

It’s just a few ideas. I would never use one Location: span_detectado.php motivated by an abnormal behavior of a user. Interaction is the key, use friendly messages without the user feeling frustrated.

The other day I downloaded my email via mobile and the server blocked my access even with password. I almost abandoned and changed my email. That is why I recommend caution not to confuse an inexperienced user with a possible threat.