consiglio sicurezza contro spam

[t1t]

Sto realizzando una community e volevo avere pareri sul sistema che pensavo di utilizzare (evitando di usare captcha)

1) per la registrazione chiedo solo username, password ed email
2) con la mail avviene l'attivazione dell'account
3) la prima volta che l'utente cerca di loggarsi appare una finestra dove inserire ulteriori informazioni obbligatorie che mi servono per gestire la community
4) inserite le informazioni il profilo è attivo e può cominciare ad usare gli strumenti della community...


i bot sicuramente mi riempiranno la prima form di spam... ma sono anche in gradi di effettuare l'attivazione tramite la mail che il mio sistema invia..... e sopratutto poi andare a loggarsi e riempirmi il form per l'attivazione completa?


da quello che so dovrebbero star li a crearli ad hoc per il mio sito...
nei forum phpbb ho avuto esperienza che riuscivano ad attivare l'account dopo la mail però cambiato il nome di un po' di variabili e campi non son più riusciti a rompere le scatole...


accetto qualsiasi critica/consiglio/insulto

[alcio74]

Insulti non li meriti proprio!
Chi vuole proteggere la propria applicazione dagli spammers è degno di rispetto!
Scherzi a parte.
Permettere le interazioni in una community solo agli utenti iscritti, potrebbe essere molto utile per evitare inserimenti da parte di BOT.
Questo però non significa che puoi abbassare la guardia, soprattutto perché, a mio modesto parere, lo spam adesso come adesso è il minore dei mali.
Se un hacker si iscrivesse alla tua comunity (regolarmente) per provare a bucare il tuo sito e ad inserire codice malevolo e/o azioni simili, non significa che potrebbe essere facilmente rintracciabile e quindi perseguibile.

Non sottovalutare un filtraggio attento degli input e testalo in maniera tosta: dai uno sguardo alla GUIDA DI SICUREZZA IN PHP per avere informazioni e spunti in merito.

Per quello che riguarda le captcha, comunque, io non le sottovaluterei.
Se poi il tuo problema è di usabilità, sappi che io me ne sono sviluppata una completamente letterale e leggibile da qualsiasi screen-reader, per cui anche accessibile.

[t1t]

per gli hacker ed eventuali inserimenti di codice malevolo ho un pattern per controllare l'inserimento di ogni informazione tramite form con i html_entities ed escape del caso e il cast prima di inserire nel database...

il mio problema era evitare proprio lo spam...

il tuo sistema letterale ha successo con gli spammer? è affidabile anche se vengono utilizzati ocr?


grazie mille

[alcio74]

Io non uso solo le HTML entities.... ma faccio proprio un controllo di determinati caratteri con le espressioni regolari.
Ad ogni modo, ognuno ha il proprio metodo: l'importante è che regga gli attacchi.
Per gli spammers, ti dico, la captcha letterale finora sembra funzionare.
Il concetto di base è piuttosto semplice.
Nella form mostro la somma di due numeri, scritti a lettere, e chiedo che ne venga digitata la somma in maniera numerica.
Semplice, leggibile, in linea stilistica con il proprio sito e accessibile anche con lo screen-reader per ipovedenti.
Finora sembra funzionare.

[t1t]

io le espressioni regolari le uso per determinati campi dei quali conosco il contenuto (password, username, mail, cap ecc..) però dei campi generici di testo eseguo solo una pulizia dei tag o con html_entities o con strip_tags... e poi un bel mysql_escape_string... tu crei espressioni regolari anche per campi che possono avere i valori più disparati (nel caso di un lungo campo di testo non sono anche lente le operzioni di confronto tra stringhe?)


ritornando alle captcha mi sa che proverò il tuo metodo!

[alcio74]

Originariamente inviato da t1t
tu crei espressioni regolari anche per campi che possono avere i valori più disparati (nel caso di un lungo campo di testo non sono anche lente le operzioni di confronto tra stringhe?)

I testi lunghi, comunque testi sono.
Salvo indicazioni particolari (come per esempio inserire un codice PHP in un sito di tutorial), un testo è un testo per cui creo una regexp che lasci passare tutti i caratteri alfanumerici, i caratteri di punteggiatura e le parentesi tonde, per esempio.
Io poi, splitto il discorso in due.
Una funzione di controllo sulla genuinità dei testi, l'altra (successiva) che sostituisce i caratteri speciali (ma io uso GET_HTML_TRANSLATION_TABLE()) nelle omologhe entità XML-friendly, così ho anche i testi validabili per XHTML Strict.