Purga stringhe PHP

[.Kurt]

e perchè mai? non è che la libreria PHP abbia chissà quali capacità voodoo, intendo rispetto a un programma qualsiasi

La differenza tra una funzione/libreria scritta da te ed una scritta da una pluralità di esperti dovrebbe essere abbastanza evidente. Per lo stesso motivo nessuno si sognerebbe di costruirsi una funzione fatta in casa per criptare/decriptare informazioni sensibili, o di usare un browser costruito dal mio vicino di casa.

La domanda è più modesta, ovvero
"con una funzione del genere sto sicuro sia per quanto riguarda injection che xss?"
Se la risposta è SI' allora per me va bene.

Più che quotare il mio precedente messaggio non so che dirti.

[brancomat]

La differenza tra una funzione/libreria scritta da te ed una scritta da una pluralità di esperti dovrebbe essere abbastanza evidente.ì

mi spieghi dove sarebbe la differenza, se la procedura è di una decina di righe?
correntemente sto rifinendo un pochino per gestire meglio il caso di eliminazione dei caratteri, ma sono fiducioso di trovare il consenso di una vasta plurarità di esperti

[.Kurt]

specie sul "Dovresti fare l'escape dei caratteri" come se filter_var non lo facesse.

Te lo confermo, filter_var non lo fa, non è il suo scopo: https://www.google.it/webhp?sourceid...in+programming

A dirla tutto per verificare il campo email basta verificare l'esistenza MX DNS (cosa di due righe in PHP) così sei sicuro che non ti basta inserire: cacca@cacca.it per superare il controllo, quindi lasciamo stare escape e check caratteri ti basta mettere quella condizione.

No, è insufficiente. Validare una email è una delle cose più difficili da fare. Email come "Abc\@def"@example.com sono valide e potrebbero essere usate. Volete proteggervi da sql injection? Usate le stramaledettissime prepared statements: http://stackoverflow.com/questions/6...jection-in-php
Questo ovviamente vale anche per te, visto che è un problema presente anche nel tuo portfolio: http://www.marcoingraiti.it/portfoli...()),9%20--%20#

[MiWebDesign]

Questo ovviamente vale anche per te, visto che è un problema presente anche nel tuo portfolio: http://www.marcoingraiti.it/portfoli...()),9%20--%20#

Non mi stupisce, Non ho mai controllato nulla nel mio sito, il calzolaio ha sempre le scarpe bucate.

Grazie per avermelo fatto notare

[.Kurt]

a dir la verità su stackoverflow ho visto la codifica hex, ma non ho ancora ben riflettuto su come usarla, la utilizzo per la spedizione di nome utente e password

Eh?

La domanda resta: se taglio via tutto quello che non è alfanumerico, sia in input dall'utente, sia prima di postare sul db, non ottengo un livello di sicurezza valido, senza complicarmi la vita più di tanto?

Ma ti abbiamo già risposto più di una volta
E' sicuro? No. Prendi come esempio

$sql = "INSERT INTO utenti (userid) VALUES (". solo_caratteri_alfanumerici($userid) .")";

Questo è vulnerabile.

$sql = "SELECT name FROM utenti WHERE id = ". solo_caratteri_alfanumerici($name);

Questo è vulnerabile.
In più ti stai complicando la vita. Un'applicazione che va in crisi solo perché ho deciso di terminare una frase con un punto (.), o mettere tra virgolette (") una parola, o impossibilitato a scrivere un banale indirizzo email (@), è un'applicazione con dei grossi limiti, oltre ad essere immensamente complicata da gestire. Inoltre queste limitazioni sono gratuite, imposte da te senza un reale motivo.

mi spieghi dove sarebbe la differenza, se la procedura è di una decina di righe?

Un po' mi secca spiegarlo. Tu stai re-inventando la ruota. Al momento hai preso un blocco di roccia e l'hai scolpita dandogli una forma a ciambella. Ma rimane sempre uno strumento inutilizzabile, per te e per gli altri: non ci fai nulla. Quindi cosa dovresti fare? Cos'è più semplice fare? Riprovare a costruire la ruota come disco di legno con un foro centrale? Oppure utilizzare la ruota che tutti usano, prepared statements, con cerchione e pneumatico?
In ogni caso, dopo anni di fatica a migliorare la tua ruota, scoprirai infine che somiglia tantissimo a quella che noi abbiamo usato tutto questo tempo.

[brancomat]

Eh?

E' in uno dei link che mi sono stati messi proprio in questo thread
perchè li leggo

Ma ti abbiamo già risposto più di una volta
E' sicuro? No. Prendi come esempio

$sql = "INSERT INTO utenti (userid) VALUES (". solo_caratteri_alfanumerici($userid) .")";

Questo è vulnerabile.

$sql = "SELECT name FROM utenti WHERE id = ". solo_caratteri_alfanumerici($name);

Questo è vulnerabile.

Non è questo che mi interessa, uso solo statement PDO.
Quello che mi interessa è la concatenazione del NOME DELLA TABELLA, dove PDO non funziona.

In più ti stai complicando la vita. Un'applicazione che va in crisi solo perché ho deciso di terminare una frase con un punto (.), o mettere tra virgolette (") una parola, o impossibilitato a scrivere un banale indirizzo email (@), è un'applicazione con dei grossi limiti, oltre ad essere immensamente complicata da gestire. Inoltre queste limitazioni sono gratuite, imposte da te senza un reale motivo.

Non so dove sarebbe "immensamente complicata", per la verità sto cercando i seguire i dettami della "bibbia" della sicurezza (OWASP.org).
A me, francamente, consentire un nome utente con ., " o quello che vuoi frega proprio niente.
Ma davvero zero.
Così come durante l'upload dei file "purgo" superbrutalmente i nomi, se uno vuol chiamare un file foto@@@òçòa@wed"$$$###.jpg (o magari http://evil/sto.jpg) io lo rinomino foto.jpg e buonanotte

Un po' mi secca spiegarlo. Tu stai re-inventando la ruota. Al momento hai preso un blocco di roccia e l'hai scolpita dandogli una forma a ciambella. Ma rimane sempre uno strumento inutilizzabile, per te e per gli altri: non ci fai nulla. Quindi cosa dovresti fare? Cos'è più semplice fare? Riprovare a costruire la ruota come disco di legno con un foro centrale? Oppure utilizzare la ruota che tutti usano, prepared statements, con cerchione e pneumatico?
In ogni caso, dopo anni di fatica a migliorare la tua ruota, scoprirai infine che somiglia tantissimo a quella che noi abbiamo usato tutto questo tempo.

francamente non ho capito nulla.
La "ruota" non è mica farina del mio sacco, viene da qui, e sembrerebbe far parte proprio delle best practices per siti sicuri
https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

In sostanza voglio 1) "demolire" SQL injection sul nome delle tabelle. A dir la verità penso di fare ancora meglio con un concatenatore di stringhe che opera con un vero e proprio switch (cioè può prendere solo una delle tabelle che voglio, approccio a whitelist, ci sto lavorando)
2) impedire qualsiasi possibilità di XSS perchè taglio via senza pietà tutto in input, e tutto in output (prima di fare il bind con PDO)
Cioè mi voglio fare una funzione (quando imparerò magari un metodo della classe) che opera qui

$stmt->bindValue(':name', PURGA($name), PDO::PARAM_STR);
purgando senza pietà (sempre approccio safe by default).
In sostanza sul db non si possono scrivere nè leggere campi se non purgati,
per il semplice fatto che sono tutti statement preparati e usando un "bindpurga" automaticamente non posso dimenticarmi di usarlo da qualche parte (al massimo userò grep per controllare)

Penso farò due funzioni diverse, purga "generica" e "speciale" per i nomi dei file.
Magari apro un altro thread per gli oggetti, per ora farò qualcosa del genere
function bindpurga($i_statement,$i_segnaposto,$i_valore)
$i_statement->bindValue($i_segnaposto,PURGA($i_valore)...)

3) sostituire a echo, print etc funzioni "sicure", cioè che per default taglino via tutto quanto, per avere una "sicurezza by default" e non il contrario
4) me ne frego (anzi, strafrego) di consentire all'utente di fare quello che vuole. fa quello che voglio io (cioè sceglie all'interno delle scelte a whitelist che consento, non a blacklist) Poi c'è l'argomento sistemistico ma lo sto approcciando con calma, prima volevo sistemare possibilmente gli script PS. il testo è sottolineato non so perchè pazienza non ho fatto io questo script

[badaze]

Ma a questo punto invece di purgare le stringhe; converti i caratteri nel loro valore numerico e salvi cosi. Poi converti di nuovo in alfanumerico prima di stampare a video. Ti costa un po' di spazio disco ma non devi più farti delle domande se rimpiazzare o meno una parola e di sicuro eviti ogni tipo di SQL injection.

[brancomat]

Ma a questo punto invece di purgare le stringhe; converti i caratteri nel loro valore numerico e salvi cosi. Poi converti di nuovo in alfanumerico prima di stampare a video. Ti costa un po' di spazio disco ma non devi più farti delle domande se rimpiazzare o meno una parola e di sicuro eviti ogni tipo di SQL injection.

Se l'ho capito bene è l'approccio hex (o comunque con questa filosofia).
Però poi non posso cercare agevolmente le informazioni

[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".