Newsgroup: it.comp.www.php
Titolo: Perchè non è buona norma usare le regexp per validare/satinizzare gli input?

Spero riusciate a spiegarmelo bene, perchè ho chiesto su altri forum
ma la risposta più concreta è che le regexp un pò complesse sono poi
difficili da capire cosa lasciano passare e cosa no, quindi difficili
da mantenere.
Il che è vero, ma dal mio punto di vista non è un problema così grosso
(basta abbondare con i commenti e per metà si risolve, cmq.)
Quindi, perchè basarsi su un preg_match per sia validare che
satinizzare un input è sbagliato?
Nel mio caso, per satinizzare intendo rifiutare: se il valore inserito
non rispetta la regexp o fermo tutto, o lo azzero.
La situazione è più che altro per difendersi dalle sqj injection, per
l'html passo tutto a htmlpurifier e qualche altra funzioncina.
p.s: non venitemi a dire di usare i prepared statements: lo faccio
già ;)

non rispetta la regexp o fermo tutto, o lo azzero.
Fermare tutto potrebbe essere piu' indicato; o e' un errore o e' qualcuno
che fa il furbo, nel qual caso e' bene che sappia di essere al guinzaglio
corto.
Leonardo
-- 
Los pellegris perjurs, fraiditz,
Qi nos an sai en camp geqitz,
Qi los manten e cortz es tortz,
Que chascuns val mens vius que mortz.

 corto.
Il bello delle regexp è che sono identiche sia su php che su js,
quindi con javascript posso avvertire l'utente prima che invii il
form, e in questo modo il 99% dei problemi meli tolgo, poi l'ultimo
controllo lo faccio da php prima di inserire a db.
Quindi se qualcuno passa il js e arriva al php con un input errato, o
ha il js disabilitato (e gli ripropongo il form) o lo ha fatto
apposta.

regexp sia il male, ma non ho ben capito perch�..
Mah... alla domanda "bastano, le regexp?", io t'avrei risposto "Dipende,
per cui non prenderle come fossero uno scudo di diamante aprovato" (cosa
che per� gi� sai, vedo).
regexp + escaping dell'SQL, in questo caso specifico, fanno tutto quello
che chiedi: anche se si verificasse il caso (imho, improbabile) proposto
da Frank Farmer, l'escaping lo neutralizzerebbe.
I livelli di errori che mi vengono in mente sono:
* Errori di contenuto ("l 
se...@gmail.com
"), che becchi con le regexp;
* SQL injection, che elimini con sql_quote + prepared statement;
* XSS, che elimini con regexp + purifier;
* Errori nella logica, che contieni (eliminarli e' dura) con STO, ovvero
  criptando/hashando gli input (ad esempio: l'immagine di un prodotto e'
  fornita con image.php?id=12345. Se mettendo id=9876543 vedo l'immagine
  di un prodotto che non avrei diritto di sapere neanche che esiste, non
  � un errore di contenuto - 9876543 � valido; non � SQL injection, dato
  che la SELECT opera correttamente; ma non deve succedere. Posso creare
  dei controlli aggiuntivi, controllando che davvero l'utente abbia ogni
  diritto su IMG9876543; e questo � "logic-dependant"; oppure posso fare
  il furbo e inviare id=12345*a3f9*. Tutte le variabili di una lista che
  specifico in un include unico per tutto il sito, DEVONO finire con i 6
  caratteri \*([0-9a-f]{4})\*... e la parte che precede, preceduta dalla
  parola segreta "puppa", md5ata e troncata ai primi 4 caratteri, dovra'
  corrispondere. Una sicurezzina da nulla, ma scoraggia tanto [1]).
* Altro, che � dove mi fregheranno, se gi� non lo hanno fatto :-)
Leonardo
[1] oh, con 32768 tentativi in media ce la fai; peccato che a quel punto
    l'utente � buttato fuori per tentato DoS <g>. Ma se non basta, senza
    allungare troppo gli ID si possono usare sei caratteri, od otto.


     allungare troppo gli ID si possono usare sei caratteri, od otto.
con un sha256 devono proprio divertirsi.. cmq l'intento è di bloccare
coloro che vogliono accedere a contenuti a loro negati e i ragazzini
che si credono hacker a giocare con le injection; un cracker vero ti
buca il server in altro modo, non con injection

buca il server in altro modo, non con injection
Siamo sulla stessa lunghezza d'onda :-)
Leonardo
