Time access restriction with php

4

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

The user can access a maximum of 4 times for intervals of 7 seconds, if he accesses more than 4 times that particular page of data within 7 seconds, the system understands how a bot and redirects the user to another location to "divert" traffic or perform other security measures.

This was the experimental code I developed along with some friends.

NOTE 1: I'm not a PHP expert, I'm always in constant learning, so tips and methodologies are always welcome.

NOTE 2: The idea is to redirect bots to avoid sending spam or even attacks like brute force , so it's a code generic 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 came from a situation where they tried to send spam to a contact form on my page and from some clients, I both added a CAPTCHA and it worked very well, but I did not want to force the user to type the CAPTCHA , I would like to create something that detects that it 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.

    
asked by anonymous 05.10.2014 / 05:54

1 answer

8

Sorry, but this will be more of a shot in the foot 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 code, once installed, allow spammers to use the machine to send spam, without the user's knowledge. While using compromised machines to perform their activities, they make it difficult to identify the source of the spam and the authors as well. Spam zombies are much exploited by spammers, providing the anonymity that protects them so much. Font

A lot of SPAM is sent by infected computers and users do not even know it. Your form can be accessed:

  • For several different machines at one time
  • By the same machine at different times
  • If your idea is to try to prevent the submission, these two cases above would be out of their logic.

    I do not think this is the way to avoid SPAM. One possible solution would be to validate the user-agent and check the incidence of submissions by that machine, along with the sender's data, and the message itself.

    But it will be 'measures' that will not guarantee that all locks will be SPAM or that the submissions are legitimate.

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

    Update

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

  • After X attempts within a period of X minutes, you can include the captcha code
  • You can request additional account information such as the date of birth or other information
  • Check how many accounts the same machine is trying to access
  • You can create an algorithm to compare the similarity of the registered password with the password used in the login
  • These are just a few ideas. I would never use a 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 accessed my email on my cell phone and the server blocked my access even with a password. So I caution you not to confuse an inexperienced user with a possible threat.

        
    05.10.2014 / 07:02