Purga stringhe PHP

[Santino83_02]

Se vuoi possiamo fare una discussione analoga e infinita sull'opportunità o meno di creare tabelle a) a nome dinamico e b) con nome PRESO DALL'INPUT DELL'UTENTE!! Ma stai facendo un gestionale per creare un db da interfaccia web o è una scelta (scellerata) di organizzazione dei dati? Perchè, mentre nel caso A avresti "ragione" dal momento che il nome della tabella lo devi pulire perchè pdo non lo farebbe per te, nel secondo caso è (ihmo stra-ihmo ma molto ihmo-fondato) una cosa sensa senso e inutile e pericolosa, quando ti basterebbe una fk tra due tablle invece di avere N tabelle che non servono a nulla.

purgare i dati prima di passarli al prepared statement non ha senso, perchè il prepared statement lo fa in automatico, non nel senso che purga i valori, ma nel senso che si assicura che il valore non modifichi la query e quindi che tu non abbia sql injection. Poi, se vuoi essere sicuro che nel campo A ci siano solo lettere e numeri, allora te li "purghi" a mano nei modi piu disparati. Se poi questi valori li usi per generare nomi delle tabelle, allora guarda fai prima a far si che i il valore sia fatto solo da lettere e numeri e senza spazi, al limite gli underscore, perchè tutti gli altri caratteri non andrebbero bene. Ma questo non è pulire il codice dell'utente per evitare sql injection (perchè lo fa pdo), ma è "VALIDARE" l'input dell'utente per garantire un corretto comportamento dell'applicativo. Ad esempio, se un campo accetta solo interi, e l'utente ti passa anche delle lettere, PRIMA di passare il tutto a PDO validi l'input per essere sicuro (lato applicativo) che i dati passati rispettino la logica del sistema, e dopo li dai a PDO. Se non lo fai, l'utente può pure passarti "DROP TABLE USERS" nelle varie forme da SQL injection, ma tutto quello che otterrai sarà un'eccezione sul tipo di dati non compatibile

Per il resto, quel bel link che hai postato te te lo dice a chiare lettere: usa un ORM (evitando ovviamente di creare query con l'input dell'utente) e usa template engine per stampare output. Poi vabbeh entriamo nell'annosa questione "perchè utilizzare un template engine ulteriore se lo è già php di suo", ma hanno tutta una serie di funzionalità comode per far concentrare il programmatore solo sulla logica dell'applicativo e non sul come realizzare (es: normalmente fanno l'escape in automatico delle stringe che stampi proprio per evitare injection varie).

Poi una domanda: ma una tabella non la posso chiamare "tabellaINSERTO" secondo te? no perchè la funzione che hai postato me la converte in "tabellaO" -_- Quindi non vendere il tuo programma ai giornalai

A giudicare da come hai risposto, il problema è a monte, nella struttura generale dell'applicazione. Rivedi quella, e poi pensi a come implementarla, non "penso come ad implementarla e poi la rivedo".

Pure quello che dici, delle "whitelist", quello è validare l'input, non purgare, e poi essere sicuri che il valore scelto lato client (il browser web) sia valido anche lato server (lo script php), perchè cambiare o bypassare la parte client non ci vuole nulla, sta alla parte server garantire i dati

ah poi un'ultima considerazione di esperienza personale: salva i dati inseriti dall'utente nel modo piu "originale" possibile, perchè se tu li elabori in un modo che ora ti sembra figo, e dopo scopri che esiste un modo molto piu figo (o anche solo che cambiano le esigenze), rischi di ritrovarti con dati incompatibili.

Quindi io arriverei a due conclusioni: 1) non usare quella funzione oppure spiega chiaramente in quali casi e per quale motivo ti serve, perchè impiegata su tutto "non serve a nulla" e ci sono anche soluzioni migliori a seconda dei casi, 2) rivedere l'architettura generale e capire veramente dove stanno i punti deboli e rinforzarli in maniera opportuna, piuttosto che idealizzare una "sicurezza by default" che non esiste, perchè il problema sei tu, non è ne l'utente (che poverino, digita tasti a caso sulle tastiere) nè del linguaggio che usi, ma il problema è quello che dici al linguaggio di fare. lì, nel 99,999% dei casi è il bug.

[k.b]

Ma questo non è pulire il codice dell'utente per evitare sql injection (perchè lo fa pdo), ma è "VALIDARE" l'input dell'utente per garantire un corretto comportamento dell'applicativo. Ad esempio, se un campo accetta solo interi, e l'utente ti passa anche delle lettere, PRIMA di passare il tutto a PDO validi l'input per essere sicuro (lato applicativo) che i dati passati rispettino la logica del sistema, e dopo li dai a PDO.

Esatto, la validazione e' un altro discorso, e comunque un dato non validato deve generare una exception, non deve essere "ripulito".

[brancomat]

Esatto, la validazione e' un altro discorso, e comunque un dato non validato deve generare una exception, non deve essere "ripulito".

Intervengo su questo aspetto: secondo le "best practices" non è il modo giusto di operare.
O meglio non il migliore.
Perchè basta che dimentichi UNA volta di "sanificare" l'input che la frittata è fatta (viene ripetuto come concetto più volte).
Qualsiasi approccio che sia insicuro per default porta a rischi.
Un po' come mettersi in casa del materiale esplosivo: certo se non gli dai fuoco non esplode.
Però basta una distrazione e booooom.

[k.b]

Intervengo su questo aspetto: secondo le "best practices" non è il modo giusto di operare.
O meglio non il migliore.
Perchè basta che dimentichi UNA volta di "sanificare" l'input che la frittata è fatta (viene ripetuto come concetto più volte).
Qualsiasi approccio che sia insicuro per default porta a rischi.
Un po' come mettersi in casa del materiale esplosivo: certo se non gli dai fuoco non esplode.
Però basta una distrazione e booooom.

E' un'obiezione che non ha senso. "Basta dimenticarsi una volta" si applica a qualunque ambito e qualunque approccio, basta che ti dimentichi una volta uno dei tuoi purgavalore() e sei nella stessa identica situazione.

Non esiste nessun paradigma che ti metta al sicuro dagli errori del programmatore.

[brancomat]

E' un'obiezione che non ha senso. "Basta dimenticarsi una volta" si applica a qualunque ambito e qualunque approccio, basta che ti dimentichi una volta uno dei tuoi purgavalore() e sei nella stessa identica situazione.

Non esiste nessun paradigma che ti metta al sicuro dagli errori del programmatore.

Invece sì.
Nel senso che la procedura che salva nel db (ad esempio) purga sempre i dati.
E chiami quella (prima o poi imparerò a fare un metodo della classe).
Quindi non puoi evitare di usarla.
Analogamente facendo un grep degli "echo" e sostituendo con "write" o "echopurgata", print_r e così via usi sempre funzioni "sicure per default"

[k.b]

Invece sì.
Nel senso che la procedura che salva nel db (ad esempio) purga sempre i dati.
E chiami quella (prima o poi imparerò a fare un metodo della classe).
Quindi non puoi evitare di usarla.
Analogamente facendo un grep degli "echo" e sostituendo con "write" o "echopurgata", print_r e così via usi sempre funzioni "sicure per default"

Esattamente la stessa cosa la puoi fare mandando i dati in output al browser quando li prendi "sporchi" dal database (cioe' usando un templating engine o equivalente fatto da te).

Tu fai (ovviamente schematizzo al minimo per rendere l'idea):
prendi dato -> purga() -> salva -> echo dato
io faccio:
prendi dato -> salva -> echo pulisci(dato)

richiede lo stesso livello di attenzione (cioe' usare una funzione): usi sempre quella e "non ti puoi dimenticare di usarla".

[brancomat]

Se vuoi possiamo fare una discussione analoga e infinita sull'opportunità o meno di creare tabelle a) a nome dinamico e b) con nome PRESO DALL'INPUT DELL'UTENTE!! Ma stai facendo un gestionale per creare un db da interfaccia web o è una scelta (scellerata) di organizzazione dei dati? Perchè, mentre nel caso A avresti "ragione" dal momento che il nome della tabella lo devi pulire perchè pdo non lo farebbe per te, nel secondo caso è (ihmo stra-ihmo ma molto ihmo-fondato) una cosa sensa senso e inutile e pericolosa, quando ti basterebbe una fk tra due tablle invece di avere N tabelle che non servono a nulla.

Servono, anzi sono indispensabili.
Essenzialmente N clienti hanno N tabelle (pippo_documenti, pluto_documenti, sempronio_documenti) uguali, ma ovviamente sono diversi (i clienti), e non è che siano proprio contenti qualora "mischiassi" i dati.
Tra l'altro renderebbe moooolto difficile, se non impossibile, backup e restore selettivo di un singolo cliente.
Poi ogni cliente ha K viste sulle tabelle, ognuna per ogni utente.
Quindi l'utente ugo dell cliente pippo ha una vista ugo_pippo_documenti con la quale vede solo i suoi dati, mentre l'utente rosso ha una vista rosso_pippo_documenti e così via.
L'utente mysql che usa gli script PHP ha grant SOLO sulle viste, o meglio sulle porzioni di viste, per i singoli utenti.
Pertando per capirci il programma PHP non può (in teoria!) vedere informazioni diverse rispetto a quelle previste, perchè il suo utente non lo può fare

purgare i dati prima di passarli al prepared statement non ha senso, perchè il prepared statement lo fa in automatico...

A dir la verità non lo fa minimamente, perchè non tiene conto di XSS e quindi di pezzi html, css o javascript

...allora te li "purghi" a mano nei modi piu disparati.

Secondo quanto ho letto non è l'approccio migliore, perchè è insecuro per default.
Va rovesciata la logica: non è che posti tutto quello che vuoi, e io cerco di metterci delle "pezze" a destra e a manca.
Posti solo quello che voglio io, e il meccanismo è automatico, non puoi dimenticarlo o eluderlo (sicuro per default).
Ppoi eventualmente in certi casi, dove è necessario, si "allarga" il cordone.

Se poi questi valori li usi per generare nomi delle tabelle, allora guarda fai prima a far si che i il valore sia fatto solo da lettere e numeri e senza spazi, al limite gli underscore, perchè tutti gli altri caratteri non andrebbero bene.

E' proprio quello che ho fatto

Ma questo non è pulire il codice dell'utente per evitare sql injection (perchè lo fa pdo), ma è "VALIDARE" l'input dell'utente per garantire un corretto comportamento dell'applicativo.

Non so come si chiami, quello che voglio impedire è SQL injection sulla creazione del nome della tabella (anzi della vista). Poi come o perchè si chiami non so, lo imparerò.

Ad esempio, se un campo accetta solo interi, e l'utente ti passa anche delle lettere, PRIMA di passare il tutto a PDO validi l'input per essere sicuro (lato applicativo) che i dati passati rispettino la logica del sistema, e dopo li dai a PDO. Se non lo fai, l'utente può pure passarti "DROP TABLE USERS" nelle varie forme da SQL injection, ma tutto quello che otterrai sarà un'eccezione sul tipo di dati non compatibile

Lo ripeto: uso solo statement PDO quindi questo problema non mi interessa, lo dò per risolto

Per il resto, quel bel link che hai postato te te lo dice a chiare lettere: usa un ORM (evitando ovviamente di creare query con l'input dell'utente)

Non so (ancora) bene cosa sia un ORM, lo studierò

e usa template engine per stampare output.

E' la mia funzione write, sarà un "template engine" dei poveri, ma mi accontento...
Come vedi ho seguito pedissequamente, nel limite delle mie conoscenze, proprio i consigli

Poi una domanda: ma una tabella non la posso chiamare "tabellaINSERTO" secondo te? no perchè la funzione che hai postato me la converte in "tabellaO" -_- Quindi non vendere il tuo programma ai giornalai

Il nome delle tabelle le decido io, non lo decide l'utente.
Quindi no, non si può chiamare INSERTO, o "droppa", o "altera"

A giudicare da come hai risposto, il problema è a monte, nella struttura generale dell'applicazione. Rivedi quella, e poi pensi a come implementarla, non "penso come ad implementarla e poi la rivedo".

Non so se la struttura è buona, a me sembra che faccia quelo che deve fare, però "trust no one" e quindi cerco di studiare il modo per migliorarla, per quanto possibile.

Pure quello che dici, delle "whitelist", quello è validare l'input, non purgare, e poi essere sicuri che il valore scelto lato client (il browser web) sia valido anche lato server (lo script php), perchè cambiare o bypassare la parte client non ci vuole nulla, sta alla parte server garantire i dati

Boh io lo chiamo "purgare", poi ci sarà un termine tecnico più adatto

ah poi un'ultima considerazione di esperienza personale: salva i dati inseriti dall'utente nel modo piu "originale" possibile, perchè se tu li elabori in un modo che ora ti sembra figo, e dopo scopri che esiste un modo molto piu figo (o anche solo che cambiano le esigenze), rischi di ritrovarti con dati incompatibili.

Francamente non ho capito cosa significhi, per me "figo" sono banali campi stringa, interi e date di mysql

Quindi io arriverei a due conclusioni: 1) non usare quella funzione oppure spiega chiaramente in quali casi e per quale motivo ti serve, perchè impiegata su tutto "non serve a nulla" e ci sono anche soluzioni migliori a seconda dei casi, 2) rivedere l'architettura generale e capire veramente dove stanno i punti deboli e rinforzarli in maniera opportuna, piuttosto che idealizzare una "sicurezza by default" che non esiste, perchè il problema sei tu, non è ne l'utente (che poverino, digita tasti a caso sulle tastiere) nè del linguaggio che usi, ma il problema è quello che dici al linguaggio di fare. lì, nel 99,999% dei casi è il bug.[/QUOTE]

[k.b]

A dir la verità non lo fa minimamente, perchè non tiene conto di XSS e quindi di pezzi html, css o javascript

Non lo fa perche' non e' il suo mestiere. XSS, html, css, javascript non significano nulla e non pongono nessun pericolo per il database, hanno significato solo se li metti in una pagina visualizzata da un browser, motivo per cui ha senso prendere le dovute precauzioni quando invii quei dati a un browser e non quando li salvi nel database.