Intervengo su questo aspetto: secondo le "best practices" non è il modo giusto di operare.Originariamente inviata da k.b
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.
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"
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
A dir la verità non lo fa minimamente, perchè non tiene conto di XSS e quindi di pezzi html, css o javascriptpurgare i dati prima di passarli al prepared statement non ha senso, perchè il prepared statement lo fa in automatico...
Secondo quanto ho letto non è l'approccio migliore, perchè è insecuro per default....allora te li "purghi" a mano nei modi piu disparati.
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.
E' proprio quello che ho fattoSe 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.
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ò.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.
Lo ripeto: uso solo statement PDO quindi questo problema non mi interessa, lo dò per risoltoAd 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
Non so (ancora) bene cosa sia un ORM, lo studierò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' la mia funzione write, sarà un "template engine" dei poveri, ma mi accontento...e usa template engine per stampare output.
Come vedi ho seguito pedissequamente, nel limite delle mie conoscenze, proprio i consigli
Il nome delle tabelle le decido io, non lo decide l'utente.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
Quindi no, non si può chiamare INSERTO, o "droppa", o "altera"
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.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".
Boh io lo chiamo "purgare", poi ci sarà un termine tecnico più adattoPure 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
Francamente non ho capito cosa significhi, per me "figo" sono banali campi stringa, interi e date di mysqlah 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.[/QUOTE]
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.
Ecco i nomi dei file sono forse l'unica eccezione, un po' perche' alcuni filesystem hanno limitazioni riguardo cos'e' lecito come nome, un po' perche' il nome originale del file raramente e' un dato importante (e anche in quel caso puoi salvarlo nel database), e un po' perche' molto spesso e' piu' utile riscriverlo in un formato adatto alla specifica applicazione.
Usi prepared statement per inserire in sicurezza i tuoi dati nel database, questo è tutto. Cosa fare con quei dati è un problema tuo: quando li salvi il database non è onnisciente al punto tale da sapere dove vorrai usarli ed in quale contesto.A dir la verità non lo fa minimamente, perchè non tiene conto di XSS e quindi di pezzi html, css o javascript
La tua intenzione è di rimediare tu stesso "purgando" i dati prima di salvarli, ed utilizzandoli così come sono quando li vai a recuperare. Questo è un errore. Perché:
1. Come ti hanno già detto ti salvi dati corrotti. L'input inserito dall'utente non corrisponderà a quello salvato nel database, e questo non deve succedere. Piuttosto, se a livello di applicazione c'è qualcosa che non vuoi salvare, lancia una eccezione ed informa l'utente che quello che ha inserito non va bene.
2. "Purgando" la stringa prima di salvarla nel database vincoli quei dati ad un solo utilizzo. Ma, oltre che essere stampati a video in una pagina html, potrebbero essere inviati via email, o utilizzati in altre query. Inoltre, cosa succederebbe se ti accorgessi tempo dopo che la funzione con cui vai a filtrare i contenuti manca di qualcosa? Ri-salvi tutti i dati del tuo database secondo il nuovo formato?
Il lavoro di togliere pezzi html, script, parolacce, tutte le parole che iniziano con la lettera "S", o quello che ti pare, lo fai quando vai ad utilizzare quei dati. E lo fai tenendo conto di dove li stai utilizzando: che sia dentro un < p > o come parametro di una querystring di un collegamento ipertestuale, o come stringa js, le strategie da adottare quando le stampi sono diverse.
E non basterebbero comunque. Se dovessi utilizzare parole chiave dovresti limitare il nome della tabella con delle backticks.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.
dbal\Connection::quoteIdentifier ti mostra una implementazione di come si potrebbe fare, ma cosa ben più rilevante è il commento:
Ad esempio,* NOTE: Just because you CAN use quoted identifiers doesn't mean
* you SHOULD use them. In general, they end up causing way more
* problems than they solve.
C'è un motivo per cui non puoi avere una sola tabella chiamata "documenti" con una colonna "cliente"?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.
Qualche post fa ti hanno accennato cos'è prepared statement.Eh... magari... ovviamente i dati forniti dall'utente DEVONO andare a finire nella query
Quindi, la risposta a
è un secco no.l'approccio che ho esposto può dare un livello di sicurezza ragionevole anche per un dilettante PHP ?
Puoi approfondire?Drupal ho scoperto essere un colabrodo ad esempio
Ultima modifica di .Kurt; 14-09-2015 a 13:37
Il punto è impedire l'esecuzione di codice dentro le pagine nel momento della visualizzazione (XSS o le altre 1000 sottoversioni) da parte del browser.
Se c'è del codice html, javascript etc allora, per quanto mi riguarda, è pericoloso.
Siccome non ci deve essere, lo tolgo.
Se l'utente è così idiota da mettere come "data operazione" invece di giorno mese anno <script> blablabla </script>... cavoli suoi.
O meglio faccio il contrario, consento solo quello che non è pericoloso.
Nel mio "superprogramma" per ora consento solo l'inserimento di una data, il testo ad esempio non lo puoi proprio inserire, lo prendi da un elenco già predisposto (avevo giusto aperto il relativo thread).
Nulla vieta però, in teoria e in pratica, di chiamare le pagine PHP passando "occultamente" roba "strana" in GET, POST o addirittura in casi estremi SESSION.
E lì il rischio per un principiante come me è grosso.
non è quello il rischio che mi preoccupa, ma i 10000 metodi per "iniettare" codice malevolo in tutti i modi, dalle sessioni falsificate a chi più ne ha ne metta.Questo è un errore. Perché:
1. Come ti hanno già detto ti salvi dati corrotti. L'input inserito dall'utente non corrisponderà a quello salvato nel database, e questo non deve succedere. Piuttosto, se a livello di applicazione c'è qualcosa che non vuoi salvare, lancia una eccezione ed informa l'utente che quello che ha inserito non va bene.
Il "briccone" mica si lascia fermare per così poco (ho letto tutto il papier sugli errori degli interi troppo lunghi di mysql e ancora ho i brividi... prima cosa che ho aggiunto tagliare tutti i numeri più lunghi di 9 cifre...)
Non è un punto che mi sia chiaro, i dati vengono poi elaborati da un gestionale "tradizionale" visual basic, lì il rischio è praticamente nullo (per l'esecuzione di codice malevolo).2. "Purgando" la stringa prima di salvarla nel database vincoli quei dati ad un solo utilizzo. Ma, oltre che essere stampati a video in una pagina html, potrebbero essere inviati via email, o utilizzati in altre query. Inoltre, cosa succederebbe se ti accorgessi tempo dopo che la funzione con cui vai a filtrare i contenuti manca di qualcosa? Ri-salvi tutti i dati del tuo database secondo il nuovo formato?
La cosa da evitare è che vengano modificati i dati in forma non prevista, letti più dati di quelli previsti, e impedito che i singoli utenti dei singoli clienti possano accedere "fuori dal loro orticello".
Insomma compartimentazione.
Nei vari siti che ho letto questa strategia è sconsigliata, per i motivi già indicati più volte.Il lavoro di togliere pezzi html, script, parolacce, tutte le parole che iniziano con la lettera "S", o quello che ti pare, lo fai quando vai ad utilizzare quei dati...
Se solo UNA volta te lo dimentichi apri una voragine ,perchè adotti un meccanismo insicuro per default.
Cioè ti tieni degli esplosivi in casa e, ogni volta che li tiri fuori, devi ricordarti di non fumare (analogia che ho letto)
Sì, sono 3, e li ho già scrittiAd esempio,
C'è un motivo per cui non puoi avere una sola tabella chiamata "documenti" con una colonna "cliente"?
1) facilità-difficoltà di fare backup e restore dei singoli clienti. con mysql è una rogna incredibile fare un mysqldump di solo una parte, e 1000 volte peggio fare il restore (bisogna cancellare una porzione del db e francamente non ci penso neppure lontanamente, mi sembra una fonte di disastri che aspetta il momento di "esplodere" ticchettando)
2) i clienti non vogliono mischiare i loro dati con quelli dei concorrenti (in caso di errore del programma potrebbero più facilmente vederli, e questo è davvero malissimo)
3) difesa in profondità con l'utilizzo di viste specifiche e GRANT mysql minimi (sempre seguendo il consiglio di partire dall'ipotesi peggiore, ovvero buco e compromissione di tutto e di più)
Se vai nelle "top 10 vulnerabilità del 2013" di OWASP vengono mostrati esempi dei difetti di progetto e di implementazione che colpiscono più frequentemente PHP, e come esempio concreto (spesso) quelli di drupal.Puoi approfondire?
La cosa che mi è piaciuta di più del sito è che spiega le vulnerabilità, poi mette "guarda qui come hanno bucato il programma X con questa tecnica"
Poi non ti so dire se è il sito "migliore" in assoluto, lurkando però su stackoverflow lo davano come di grande affidabilità
E' inutile continuare il discorso, ormai è evidente che hai deciso quale strategia usare. Noi più che ripeterti le stesse cose e dirti che è una pessima idea non possiamo fare altro. Alle volte è necessario sbattere contro il muro per capire certe cose, lo abbiamo fatto tutti.
Linka pure qui, e tieni sempre a mente che sul web si trovano molti articoli scritti coi piedi da gente che sulla questione ha solo sentito parlare. Non prendere per oro colato tutto quello che ti capita di leggere.Nei vari siti che ho letto questa strategia è sconsigliata, per i motivi già indicati più volte.
Così come ogni tanto si scopre che doctrine, symfony2, ed un milione di altri progetti hanno vulnerabilità. Così come php stesso. Ma mica ti fai scrupolo ad usarlo, no?Se vai nelle "top 10 vulnerabilità del 2013" di OWASP vengono mostrati esempi dei difetti di progetto e di implementazione che colpiscono più frequentemente PHP, e come esempio concreto (spesso) quelli di drupal.
Se trovi un grande progetto che non ne ha neanche una significa una cosa sola: che non è più mantenuto da nessuno.
Ultima modifica di .Kurt; 14-09-2015 a 14:25
Scusa ma francamente i consigli che ho avuto sonoE' inutile continuare il discorso, ormai è evidente che hai deciso quale strategia usare. Noi più che ripeterti le stesse cose e dirti che è una pessima idea non possiamo fare altro. Alle volte è necessario sbattere contro il muro per capire certe cose, lo abbiamo fatto tutti.
1) usa statement (e li uso già)
2) memorizza nel db qualsiasi cosa arrivi in input dall'utente (e mi sembra un rischio enorme)
3) quando mostri i dati, volta per volta, ricordati di verificare (e come?) che non siano dannosi
https://www.owasp.org/index.php/PHP_..._Sheet#No_TagsLinka pure qui, e tieni sempre a mente che sul web si trovano molti articoli scritti coi piedi da gente che sulla questione ha solo sentito parlare. Non prendere per oro colato tutto quello che ti capita di leggere.
Così come ogni tanto si scopre che doctrine, symfony2, ed un milione di altri progetti hanno vulnerabilità. Così come php stesso. Ma mica ti fai scrupolo ad usarlo, no?
Se trovi un grande progetto che non ne ha neanche una significa una cosa sola: che non è più mantenuto da nessuno.
http://www.zoubi.me/blog/drupageddon...n-exploit-demo
Permessi di invio
Rispondi quotando