Purga stringhe PHP

[brancomat]

Design che personalmente ritengo assolutamente privo di ogni senso, indipendentemente da chi l'abbia suggerito.

Lo vedi qui
http://phpsecurity.readthedocs.org/e...fense-in-depth

Non ho capito se mi prendi in giro. Se leggi bene ho detto niente input utente nella STRINGA che compone la query, i dati ovviamente ci vanno, ma separati (come parametri). Se non e' possibile (es. nomi di tabella), allora whitelist.

Lo ripeto per la 5 volta.
Non ho query "concatenate", ho tutte statement preparate PDO. La concatenazione è nel nome della tabella, ed è lì "l'inghippo"

No. L'approccio che hai esposto e' piu' compicato e meno sicuro di quelli che ti sono stati suggeriti.

Se sapessi come ridefinire la bindValue...

[.Kurt]

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.

Nei vari siti che ho letto questa strategia è sconsigliata, per i motivi già indicati più volte.

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.

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.

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.

[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]

Riguardo al contenuto pericoloso
https://www.owasp.org/index.php/PHP_..._Sheet#No_Tags

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). However, this is not recommended. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping by default - see below. All HTML should be passed out through the template engine.

e

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
//qui ci metto una purga ben più "restrittiva"...
   return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
   echo xssafe($data);
}
//usage example
<input type='text' name='test' value='<?php 
xecho ("' onclick='alert(1)");
?>' />

[k.b]

Lo vedi qui
http://phpsecurity.readthedocs.org/e...fense-in-depth

No, mi riferisco a una tabella per ogni utente.

Lo ripeto per la 5 volta.
Non ho query "concatenate", ho tutte statement preparate PDO. La concatenazione è nel nome della tabella, ed è lì "l'inghippo"

Gia', e dove va il nome della tabella? Nella stringa della query.

[k.b]

Riguardo al contenuto pericoloso
https://www.owasp.org/index.php/PHP_..._Sheet#No_Tags

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). However, this is not recommended. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping by default - see below. All HTML should be passed out through the template engine.

Che e' appunto quello che sto dicendo io, non mi pare ci sia scritto di ripulire i dati prima di inserirli nel database.

[brancomat]

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.

Scusa ma francamente i consigli che ho avuto sono
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

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

https://www.owasp.org/index.php/PHP_..._Sheet#No_Tags

http://www.zoubi.me/blog/drupageddon...n-exploit-demo

[brancomat]

No, mi riferisco a una tabella per ogni utente.

E' una tabella per cliente.
Conosci un metodo ragionevolmente semplice per fare il backup e (soprattutto) il restore di un po' di righe di una decina di tabelle mysql?
(lo chiedo così imparo qualcosa di nuovo)
Per il resto (le viste) "minori privilegi possibili"

[k.b]

Scusa ma francamente i consigli che ho avuto sono
1) usa statement (e li uso già)

ottimo, tra prepared statements e whitelisting il problema injection e' risolto

2) memorizza nel db qualsiasi cosa arrivi in input dall'utente (e mi sembra un rischio enorme)

I dati nel database non rappresentano nessun rischio, perche' da soli non fanno nulla, essendo - appunto - solo dati

3) quando mostri i dati, volta per volta, ricordati di verificare (e come?) che non siano dannosi

Con un template engine, come dice il link che tu stesso citi

[k.b]

E' una tabella per cliente.
Conosci un metodo ragionevolmente semplice per fare il backup e (soprattutto) il restore di un po' di righe di una decina di tabelle mysql?

Ometto i parametri username e password per semplicita':

# backup
mysqldump nome_db clienti -where="cliente='franco'" > franco.sql

# restore
mysql nome_db -e "DELETE FROM clienti WHERE cliente='franco'"
mysql nome_db clienti < franco.sql

Per il resto (le viste) "minori privilegi possibili"

A che pro? Il tuo applicativo avra' comunque tutte le password, e non penso tu dia gli accessi diretti al db ai clienti.