E' in uno dei link che mi sono stati messi proprio in questo thread
perchè li leggo
Non è questo che mi interessa, uso solo statement PDO.Ma ti abbiamo già risposto più di una volta
E' sicuro? No. Prendi come esempio
Questo è vulnerabile.codice:$sql = "INSERT INTO utenti (userid) VALUES (". solo_caratteri_alfanumerici($userid) .")";Questo è vulnerabile.codice:$sql = "SELECT name FROM utenti WHERE id = ". solo_caratteri_alfanumerici($name);
Quello che mi interessa è la concatenazione del NOME DELLA TABELLA, dove PDO non funziona.
Non so dove sarebbe "immensamente complicata", per la verità sto cercando i seguire i dettami della "bibbia" della sicurezza (OWASP.org).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.
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
francamente non ho capito nulla.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.
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