bot che compila i form e comando sleep...

[calcmore]

secondo voi a senso mettere una cosa tipo questo ?

if (!empty($_POST['dato_del_form'])) 
{ 
sleep(2);
...
...
...
}

cioè in pratica sarebbe tipo uno "stratagemma estremamente basico" per scoraggiare (o quantomeno rallentare) eventuali bot che autocmpilano un form molteplici volte ad alta velocità.

Se, invece, chi compila non è un bot e, magari, ci tiene veramente ad attendere l'esito dei dati che ha inserito nel form...non credo che si faccia problemi per aspettare 2 secondi di numero...

vi sembra un'idea che può avere un senso ? o no ?

[frasidipace]

Non fai prima ad integrare lo script di reCaptcha di Google?

Ciao

[mzanella]

vi sembra un'idea che può avere un senso ? o no ?

Funzionerebbe solo per bot sincroni e sequenziali. Un bot asincrono o parallelo potrebbe comunque inviare qualche migliaio di form al secondo alla tua pagina PHP.

[calcmore]

x frasidipace

Non fai prima ad integrare lo script di reCaptcha di Google?

hum... quando posso do un occhio a come funziona la cosa...

x mzanella

Funzionerebbe solo per bot sincroni e sequenziali. Un bot asincrono o parallelo potrebbe comunque inviare qualche migliaio di form al secondo alla tua pagina PHP.

hum... quindi forse è meglio una cosa del genere ? che ne pensi/pensate ?

da mettere nel momento in cui si riceve $_POST

function antibot_1min()
 {
	append_str(getIp2(),'1min.txt');

 }

da mettere a inizio pagina

function antibot_1min_start()
  {
	$stay = file2('stay.txt')[0]; //non cambiare l'indice (il file 'stay.txt' ha infatti una sola riga)
	
	if ($stay != date("i")) //se è passato più di un minuto...
	   {
		   scrivi_str(date("i"),'avventura/antibot/stay.txt');  // aggiorna 'stay.txt' al minuto corrente
		   scrivi_str('','avventura/antibot/1min.txt'); // CANCELLA lista ip del minuto precedente
	   }
	
	$arr = file2('1min.txt');
	$count = 0;
	for ($k=0; $k < count($arr); $k += 1)
	  {
		  if ($arr[$k] == GetIp2())
			  $count += 1;
	  }	
    if ($count >= 6)
	{
       echo '<br><br><strong>molti form compilati in pochissimo tempo';
       echo '</strong>...<a href="miapagina.php"><strong>riprova</strong></a> tra 1 minuto...<br><br>';		
       die();
	}
  }

ps: per far prima non ho scritto le "dipendenze"
pps: tanto tenere gli ip minuto per 1 minuto in una lista (che si auto-cancella il minuto successivo) non è (non credo) sia considerata raccolta di ip, giusto ?...

[darbula]

Senza consenso non puoi salvare un'indirizzo ip a limite blocchi la richiesta. Altrimenti Anomizza (o mascheramento o oscurare) 127.000.000.xxx l'ultimo ottetto senza consenso.
Anche se parla di Google Analytics il concetto è il medesimo https://digitalsfera.it/gdpr-e-cooki...P_di_Analytics

[mzanella]

hum... quindi forse è meglio una cosa del genere ? che ne pensi/pensate ?

Così facendo è peggio. Un bot invierà le richieste direttamente al tuo endpoint PHP, non sarà così beneducato da passare per la pagina contenente il form, quindi qualsiasi controllo tu metta in quest'ultima sarà inutile. Il peggioramento avviene perché ora l'endpoint PHP registra ogni richiesta ricevuta in un file di testo senza restrizioni.

Concretamente, immagina questo scenario. Un indirizzo IPv4 richiede almeno 4 byte per essere memorizzato. Un bot può effettuare almeno 5000 richieste asincrone al secondo. Il bot invia i dati direttamente alla pagina PHP, senza passare per quella del form (quindi il codice che pulisce il file con gli IP non viene mai eseguito). In questo modo il bot è in grado di generare 5000 * 4 byte =~ 20KB di dati al secondo, circa 72MB all'ora. Se il bot lavora per una notte intera, quando verosimilmente nessuno si registra tramite form ripulendo il file degli IP, la mattina seguente ti trovi con quasi 1 GB di spazio occupato dagli IP scritti dal bot.
E questa è una stima abbastanza ottimista, un bot parallelo può tranquillamente arrivare a più di 100k richieste al secondo (x20 ai danni), e se l'IP non è memorizzato nel migliore dei modi possibili, bensì come stringa, l'occupazione di memoria non è 4 byte, ma 15 (x4 ai danni). Così in una notte ti vanno via 80GB di spazio .
Senza contare il fatto che, man mano che la lunghezza del file degli IP cresce, il tempo per l'accesso aumenta linearmente. Sarebbe un DoS coi fiocchi.

Anziché cercare di inventare soluzioni "caserecce" ti conviene fare riferimento a metodologie già pronte. Innanzitutto un token CSFR permette di evitare che un bot invii richieste direttamente all'endpoint, costringendolo a passare per la pagina con il form. Poi un Google reCAPTCHA per ridurre il numero di bot che attaccano tramite pagina con form. Infine un meccanismo di blacklisting di subnet.
Registrare gli IP che cercano di inviare dati va bene, permette di effettuare analisi a posteriori utili per capire se inserire qualcuno in blacklist... però non in un fie di testo a manazza! Usa un database con una tabella access_log(ip INT, counter INT, last_access DATETIME) o simile.

Senza consenso non puoi salvare un'indirizzo ip [...] Anche se parla di Google Analytics il concetto è il medesimo

La questione non è così semplice. Nel caso di Analytics le informazioni sono raccolte per finalità commerciali, per le quali serve consenso esplicito. D'altro canto per i cosiddetti technical cookie, ovvero i cookie creati in quanto necessari alla fruizione di un servizio, non serve consenso. Il caso degli IP memorizzati per impedire attacchi al sito si colloca più vicino a quest'ultima casistica, se non erro c'è anche una sentenza UE che lo conferma. Per tagliare la testa al toro basta memorizzare un hash dell'IP, leggermente meno performante ma più che adeguato.

[darbula]

@maznella perdonami andiamo indietro, anche se non contemplato dalla legislatura se un ip è memorizzato su disco da terzi non può considerarsi technical cookie. Però se il webmaster (il sito non un seggetto terzo) salva su disco e dunque offre la lettura del file a chiunque applicando il buonsenso non è technical cookie (è la medesima cosa da terzi anche se non contemplato in nessuna norma). Il motivo è la privacy e la gestione dei dati che purtroppo possono identificare univocamente l'utente.

[mzanella]

[...] un ip [...] non può considerarsi technical cookie

[un IP memorizzato] per impedire attacchi al sito si colloca più vicino a quest'ultima casistica [dei technical cookies]

Nessuno ha mai detto che fosse un technical cookie.

anche se non contemplato dalla legislatura

È contemplato dalla legislatura in materia di GDPR: https://gdpr-info.eu/issues/personal-data/, il quale classifica gli IP come dati personali.

memorizzato su disco da terzi

Nel caso descritto il dato non è memorizzato da terzi (third party application), ma dal sito stesso (first party application).

salva su disco e dunque offre la lettura del file a chiunque

Non è l'uso descritto, il file sarebbe inteso unicamente al sito stesso per effettuare controlli di sicurezza. Chiaramente avrebbe dovuto adoperarsi per restringere l'accesso al file, ma quello è un altro discorso, che in ogni caso non si pone usando un database.

applicando il buonsenso

Sono d'accordo, ma se la legge si basasse sul buonsenso, questo mondo sarebbe un posto migliore.

Il motivo è la privacy e la gestione dei dati che purtroppo possono identificare univocamente l'utente.

Questo è il punto, in effetti: la memorizzazione senza processamento per soli fini di sicurezza (che si configurano come interessi legittimi del fornitore del servizio) non minacciano la riservatezza dell'utente. Mi spiego con un esempio: supponiamo che nel caso descritto sia necessario fornire consenso per il trattamento dell'indirizzo IP. Un hacker visita il sito, non presta il consenso e dunque il suo indirizzo non può essere memorizzato: ora l'hacker può lanciare tutti gli attacchi che desidera, gli interessi legittimi del fornitore non sono tutelati. Viceversa, se un utente onesto visita il sito e il suo IP viene memorizzato nelle modalità descritte senza consenso, egli non ne riceve danno né violazione della privacy.
Diversa è la questione relativa all'informativa sulla privacy, che deve essere sempre presente e trasparente.

In ogni caso: memorizzando un hash dell'IP l'intero problema non si pone a prescindere.

[calcmore]

ciao (e scusate il ritardo...)

Così facendo è peggio. Un bot invierà le richieste direttamente al tuo endpoint PHP

be è chiaro...probabilmente mi è venuta in mente quella soluzione perché spesso faccio delle semplici pagine in cui pagina contenente il form e "end point" coincidono...spero che ciò non abbia controindicazioni particolari...

In ogni caso: memorizzando un hash dell'IP l'intero problema non si pone a prescindere.

sarebbe un'idea... mi confermate che, per sicurezza di un website, dal punto di vista legislativo si può fare ?

[mzanella]

be è chiaro...probabilmente mi è venuta in mente quella soluzione perché spesso faccio delle semplici pagine in cui pagina contenente il form e "end point" coincidono...spero che ciò non abbia controindicazioni particolari...

Sì, è l'approccio più comune, almeno finché non diventa necessario un approccio REST. Nulla vieta comunque a un attaccante di scrivere due righe di codice per effettuare le richieste all'"endpoint" senza passare fisicamente per il form, per esempio

for i in {1..1000000}
do
    curl -X POST -F "parametro=valore" -F "parametro2=valore2" http://calcmore.altervista.org/miapagina.php &
done

lancia 1000000 richieste asincrone in tempi estremamente rapidi .

sarebbe un'idea... mi confermate che, per sicurezza di un website, dal punto di vista legislativo si può fare ?

Senza dubbio, gli hash non sono funzioni iniettive, quindi anche volendo non sarebbe possibile identificare qualcuno tramite hash dell'IP.

[calcmore]

ciao, sono di nuovo io...

ma il comando php per hash quale è ?... io volevo usare il cpomando md5 ma ho letto che non è indicato per questo uso, quindi devo usare il comando hash ? quale algoritmo esattamente ? (Li ne sono indicati una ventina...)

grazie a chi volesse darmi una mano

[darbula]

https://forum.it.altervista.org/pubb...ml#post1475363 il codice va sempre migliorato (non si scrive una sola volta, ma lo si migliora di volta in volta).
Sceglierne uno supportato dal tuo host, leggi questo commento https://www.php.net/manual/en/functi...ash.php#124294 (il motivo perché il codice non dovrà essere scritto ma revisionato di volta in volta).
Poi effettivamente anche l'operatore === non va bene, dovresti creare

$nomevar_stringa_form = 'testo'; //Imito manualmente l'interazione dell'utente da un form html con input nascosto
if(is_string($nomevar_stringa_form) && strlen($copynomevar) == strlen(($hash = password_hash($nomevar_stringa_form, PASSWORD_BCRYPT))) && $copynomevar === $hash && password_verify($hash, $copynomevar)) //Non considero il bug del primo byte null "\0stringa" nella precedenti versione di php https://www.php.net/manual/en/function.password-hash.php#118603 

o da php 5.6 hash_equal
Nota :

È importante fornire la stringa fornita dall'utente come secondo parametro, anziché come primo.

$copynomevar è il valore "password_hash('testo', PASSWORD_BCRYPT)" conservato nella sessione ma uso questa sintassi perché più corta.

[mzanella]

Per un hash di IP va bene qualsiasi cosa. Nel dubbio usa sha256, che è tra i più comuni:

$hashed_ip = hash('sha256', '11.22.3.44'); 

Quello che dice darbula sembra più pertinente al salvataggio delle password, per le quali il discorso è un po' diverso ed siste una fuzione apposita password_hash.

Per curiosità: dove hai letto che md5 non è adatto?

[darbula]

Appunto il bug è in algo BCRYPT di password_hash. Il salvataggio è necessario se sessione php con (file o database) per produrre il token CSFR in php.
Anche hash per un ip sarà comunque salvato (nel database).