Newsgroup: it.comp.www.php
Titolo: metodo più sicuro per trasmettere variabili

Ciao a tutti,
sto facendo un portalino in php e su suggerimento di un utente di questo ng 
(David Paleino che ringrazio) e guardando vari manuali trovati in rete, ho 
iniziato a scrivere del codice dinamico con valori etc. passati con il 
comando GET.
Quindi ho creato una tabella e nella cella di sinistra ho messo il 'modulo' 
menu dovi ogni voce è grosso modo così:
<p><a href="index.php?page=x">LINK_x</a></p>
x varia per ogni pagina etc.etc.
e la cella centrale (di destinazione) riceve il valore così:
$page=(isset($_GET['page']))?$_GET['page']:0;
switch ($page) {
case 0:
........
..................
etc.etc.
ora vi chiedo, avendo letto che GET è meno sicuro di POST e che è possibile 
usare anche $HTTP_GET_VARS e $HTTP_POST_VARS,
quale è più sicuro al fine di evitare exploits o defacciamenti da lamer?
Il mio sito è hobbistico (modellismo), quindi non uso tali funzioni per 
trasmettere dati sensibili o bancari etc.etc., mi basta restare in piedi 
allontanando malintenzionati.. :-)
Grazie tante a tutti.
Il grillo parlante 

 usare anche $HTTP_GET_VARS e $HTTP_POST_VARS,
E' quali sono le differenze di sicurezza tra get e post?
$HTTP_GET_VARS/$HTTP_POST_VARS è il "vecchio" modo di trattare le 
variabili adesso sostituito da $_GET/$_POST (nel manuale, variabili 
superglobali), ma si accede sempre ai soliti valori :-)
	Francesco	

 e che è possibile usare anche $HTTP_GET_VARS e $HTTP_POST_VARS,
Questi venivano usati con vecchie versioni di PHP. Vedi le seguenti
pagine: 
http://it2.php.net/manual/en/language.variables.predefined.php
http://it2.php.net/manual/en/reserved.variables.php
http://it2.php.net/manual/en/security.globals.php
Usa i superglobal array $_GET, $_POST, ecc... e imposta
register_globals = Off. Per garantirti un minimo di sicurezza devi
controllare sempre e comunque qualunque parametro passato a una
pagina, indipendentemente dal metodo usato per passarglielo. Nel tuo
caso, assicurati che il parametro esista, che contenga un tipo di
dato che ti aspetti (se ti aspetti un intero, assicurati che sia un
intero, se ti aspetti una stringa, assicurati che sia una stringa e
che contenga solo i caratteri permessi, eccetera...), che il file a
esso corrispondente esista (e che sia locale). Se il parametro passa
tutti i test includerai il file richiesto, altrimenti includerai un
file di defualt. Dopodiché puoi decidere quale metodo usare (GET o
POST) in base ad altri criteri. 
Ciao.
-- 
Federico

 superglobali), ma si accede sempre ai soliti valori :-)
ti ringrazio, chiarissimo.
;-) 

 malintenzionato.
E` vero fino a un certo punto.
Se usi HTML, i campi che mandi sono comunque visibili nel form, quindi
basta leggere il sorgente della pagina prima dell'invio per vedere cosa
manda.
Se usi Flash (per esempio) per fare il form, nascondi il sorgente, e
quindi i campi, ma basta uno sniffer in locale per vedere cosa viene
mandato.
In ogni caso i dati, con GET o POST, vengono mandati in chiaro, quindi un
man-in-the-middle li legge senza problemi con uno sniffer, a meno che non
usi SSL su tutte le pagine.
Sono solo leggere complicazioni che fermano i "cracker" incapaci, ma di
certo non quelli un po' meno incapaci.
E` il motivo per cui si raccomanda sempre di non fidarsi dei dati che
arrivano dal client.
Bye.

 POST) in base ad altri criteri.
in base alla tua esperienza quando defacciano un sito -escludiamo i cms- 
qual'è l'errore più comune fatto dal programmatore?
Qualcuno sa indicarmi dei links con una raccolta di 'precauzioni' da 
osservare nel programmare in php?
Grazie anche a te Federico.
ciao. ;-) 

 non mostrerebbe di conseguenza id, password e altri dati rilevanti per un 
Una cosa che non si vede, non è detto che non c'è!
L'unica limitazione è sulla lunghezza dei dati che puoi passare con un 
metodo rispetto l'altro e sulla facilità di uso. Per un get ti basta un 
link con il parametro, per un post devi mettere su una form e sumbit 
oppure lavorare con js.
Se accetti un consiglio, parti sempre dal presupposto che tutti i dati 
(sia get che post) possono essere visti e modificati a piacere da ogni 
utente, pertanto controlla sempre la loro validità e consistenza e 
contesto. Per dati come l'id dell'utente collegato, usa le sessioni.
Anni fa (tanti) un'azienda di telefonia mobile dava la possibilità di 
inviare sms via web solo ai propri numeri (implementato via post): il 
controllo era affidato a una combobox con i prefissi 03xx/03xx; è 
superfluo continuare...
Una cosa è cambiare un id di un listino e invece di vedere una padella, 
vedere una pentola, altra cosa è vedere il conto di un altro cliente!
	Francesco

 arrivano dal client.
morale della favola niente è sicuro, giusto?
Anche se con questo topic mi riferivo più ai lamer e a color che visitando 
siti hacker trovano l'exploit del momento bello e pronto con tanto di 
istruzioni da seguire per compilarlo e colpire il sito di turno.
Se evito di ricorrere a cms preconfezionati -joomla in testa- è proprio per 
avere meno rogne da questo punto di vista.
Credo che una volta che il lamer si accorge che il portale non regge su un 
cms spu**anato ma è fatto da me, e che di mezzo non ci sono chissà quali 
somme di denaro etc. dovrebbe desistere dallo studiarsi il codice per farmi 
cadere a tutti i costi.. o sbaglio?
Un sito di modellismo che pubblica informazioni e articoli gratuitamente 
potrebbe allettare quanto il sito della NASA? Se si non mi resta che farlo 
in html semplice o non farlo proprio.. :-/
Grazie per avermi risposto.

 osservare nel programmare in php?
Non è un problema di php, è un problema in programmare. Lo sai quanti 
programmi fatti in vb hanno sql injection? Il vantaggio è che se io ti 
faccio un programma in vb e te lo usi in azienda o hai uno smanettone in 
casa che ti sabota il lavoro oppure non hai problemi, se lo pubblichi al 
mondo intero, il discorso cambia!
	Francesco

 programmi fatti in vb hanno sql injection? Il vantaggio è che se io ti 
Ho citato il VB come linguaggio molto conosciuto e utilizzato, non certo 
per problemi di sicurezza nel linguaggio.
	Francesco

 ha scritto nel messaggio 
news:%wAPg.237$gT6...@nntpserver.swip.net...

tutto chiaro. Se le mie domande possono sembrarti banali ti chiedo scusa.
Un'altra domanda che mi viene in mente riguarda un'istruzione trovata sempre 
su joomla, ovvero:
defined( '_VALID_MOS' ) or die( 'Restricted access' );
in alcune guide ho letto che va inserita per evitare l'accesso diretto al 
modulo/componente/pagina in questione.
Ma se io ad es i miei articoli li inserisco in semplici pagini html esiste 
un modo per evitare che la pagina venga linkata da altri siti a mia 
insaputa?
ciao. ;-) 

 
Se hai delle semplici pagine html non hai nessun controllo in php.
Puoi mettere le pagine fuori dall'htdocs del server web e fare una 
pagina php che provvede a controllare se hai l'accesso a tale pagina e, 
se si, ti fa da "ponte" tra il server web e questa directory "protetta"
Attenzione che una pagina "ponte" è alquanto pericolosa e deve essere 
controllata in tutto e per tutto (e si torna al discorso del controllo 
dei dati immessi dall'utente o parametri passati via get/post).
	Francesco

 ha scritto nel messaggio 
news:zOAPg.241$gT6...@nntpserver.swip.net...

fine delle domande.
Ancora grazie e ciao. ;-) 

cosi' pignoli nel codice?
No: la versatilita' c'e' sempre. La pignoleria serve per darti la
sicurezza -- e quella non te la puo' dare il linguaggio: sa assai
il C, il Perl, o il PHP cosa t'aspetti da una variabile.
Eventualmente puoi (anche in PHP) inventare le variabili _POST di
tipo auto-tipizzante:
	- quelle che iniziano per i sono interi
	- quelle che iniziano per a sono stringhe a-zA-Z...
	- quelle che iniziano per q sono stringhe SQL
	- quelle che iniziano per b sono 0 o 1
e poi crearti un modulino singolo, che includi dappertutto, e che
valida l'array _REQUEST. Dato che e' un array superglobale...
	$reqexp	= array(
		'i'	=> '-*[1-9][0-9]*',
		...
	);
	foreach($_REQUEST as $key => $value)
	{
		$type = substr($key, 0, 1);
		// Oppure, anche meglio, cosi' si puo' usare "sql_campo"
		// o "str_utente" o "num_kbytes"
		// $datum = explode('_', $key);
		// if (count($datum) < 2) continue;
		// $type = $datum[0];
		if (!isset($reqexp[$type]))
		{
			// Ci si puo' mettere anche un die()
			unset($_REQUEST[$key], $_POST[$key], $_GET[$key],
$_COOKIE[$key]);
			continue;
		}
		if (!preg_match("/^$reqexp[$type]$/", $value))
		{
			// Ci si puo' mettere anche un die()
			unset($_REQUEST[$key], $_POST[$key], $_GET[$key],
$_COOKIE[$key]);
			continue;
		}
	}
Qui ovviamente il lavoro di intelligenza lo fai poi tu, quando una
variabile la chiami "num_ordine" anziche' "str_ordine".
Leonardo cosi' per discutere
-- 
Dawn is near, the time is short (Human aircraft! Hard to port!)
We eight reindeers of the night work as one in silent flight.
Let not one damn house pass by (Who taught that guy how to fly?)
Each year sees more girls and boys: how many of them can we bring toys?


if((empty($_GET['ppp'])){
    $uc = 0;
}else{
if(is_int($_GET['ppp'])){
     $uc = $_GET['ppp'];
}else{
   $uc = 0;
}
}
switch($uc){
  case 0:
  default:
include("p_00.php");  // e' la homepage o cio che deve essere la home
break;
case 1:
include("p_01.php");
break;
case 2:
include("p_02.php");
break;


 osservare nel programmare in php?
Le precauzioni da prendere sono sempre le solite e sono valide per
qualunque linguaggio di programmazione.
In linea generale puoi partire dal manuale online:
http://www.php.net/manual/en/security.php
Con Google ho trovato questa, ma non la conosco personalmente:
http://php.html.it/guide/leggi/121/guida-sicurezza-di-php/
-- 
Federico

 allontanando malintenzionati.. :-)
e questo gia' ti e' garantito non dal php ma dai settaggi lato server.
Inoltre se proprio vuoi essere invisibile a tramettere variabili e'
molto semplice e la soluzione si chiama i_frame o frame (se non ti
piacciono le i) in questo modo terresti il menu con magari il logo
fisso e cambieresti il link separatamente ma nella pagina. Mgari
utilizzando variabili di sessione e filtrando l'input della variabile
con funzioni tipo:
function GetSQLValueString($theValue, $theType, $theDefinedValue = "",
$theNotDefinedValue = "")
{
  $theValue = (!get_magic_quotes_gpc()) ? addslashes($theValue) :
$theValue;
  switch ($theType) {
    case "text":
      $theValue="'". $theValue ."'";
      break;
    case "long":
    case "int":
      $theValue = ($theValue != "") ? intval($theValue) : "NULL";
      break;
    case "double":
      $theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'"
: "NULL";
      break;
    case "date":
      $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";
      break;
    case "defined":
      $theValue = ($theValue != "") ? $theDefinedValue :
$theNotDefinedValue;
      break;
  }
  return $theValue;
}
buon lavoro ;)

 
index.php?page=/etc/passwd
questo puoi inviarlo in GET in POST tramite COOKIE
ma se non controlli la bontà del contenuto della variabile sei fregato
-- 
una volta qui era tutto <table>

Le risposte sono tutte assolutamente complete e fatte da persone
competenti, ma aggiungo anche la mia per dare uno spunto in più a chi
si accosta alla programmazione di pagine web in maniera candida e
innocente, senza pensare in quanti cerchino di scassinare un form con
un SQL-Injection appena ne trovano uno.
Prendi un sito a caso che abbia un form regolamentato da ferree
funzioni javascript.
Copia il codice della pagina in locale e cancella tutto il javascript
che blocca l'inserimento di dati inconsistenti con quanto si aspetta il
webmaster.
Invia il form utilizzando dati sgangherati (numeri con la virgola, il
punto e i temuti apicetti). Certo, il forum lo si può inviare anche da
locale. Non è necessario che la pagina risieda su un web server.
Questo è quello che ti può succedere quando fai un form o una pagina
che attende dati, sia in pos che in get. Prima o poi trovi il lamer di
turno che tenta di forzare la pagina, oppure incapsula la tua pagina in
un frameset, dove gli altri frame sono pieni di funzioni javascript che
tentano di scassinare la tua.
Ricorda che a fronte di una pagina che filtra l'input e di uno script
engine configurato correttamente (es. register_globals Off), esistono
solo exploit verso il server stesso e quì la tua responsabilità
cessa.
Buon lavoro ;)

Come da oggetto, scusate se scrivo solo ora ma in questi giorni sono 
incasinato dal lavoro..
Grazie a tutti per le risposte, siete stati molto altruisti e pazienti.
A presto. ;-)
Il grillo.