Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Vulnerabilidades en Aplicaciones Web PHP

3,327 views

Published on

Entendiendo vulnerabilidades comunes en aplicaciones web escritas con PHP

  • Be the first to comment

Vulnerabilidades en Aplicaciones Web PHP

  1. 1. Vulnerabilidades en Aplicaciones Web PHP Moisés H. Silva CIISA 2007 “ You can't consider the problem of defense without first understanding the problem of attack ” - Doug Tygar - 1
  2. 2. Agenda 1. Vulnerabilidades en PHP 2. SQL Injection * PHP, lenguaje inseguro? * Qué es? * Estadísticas * Cómo Atacar? * Cómo Protegerme? 3. Code Injection 4. Session Hijacking * Qué es? * Qué es? * Cómo Atacar? * Cómo Atacar? * Cómo Protegerme? * Cómo Protegerme? 2
  3. 3. PHP, Lenguaje Inseguro? • - Poder, Versatilidad y Facilidad son una fórmula para la inseguridad. • • - PHP ha crecido de forma desorganizada. • - Zend está intentando poner un orden, PHP5 es un gran paso. - La seguridad de un lenguaje de programación es inversamente proporcional a • la cantidad de responsabilidad delegada al programador. • • - Sólo un programador debería escribir programas , PHP se lo permite a otros. 3
  4. 4. Estadísticas - Crecimiento de PHP Fuente: http://www.netcraft.com/Survey/ 4
  5. 5. - Servicios de red más usados Fuente: http://www.securityseer.com/ 5
  6. 6. - Top 10 de vulnerabilidades web Fuente: http://www.owasp.org/ 6
  7. 7. SQL Injection Qué es? - SQL injection es el término usado para la introducción de datos en una aplicación • con la intención de ejecutar sentencias SQL para las que el sistema no fué diseñado • y/o para las cuales el usuario no tiene privilegios. • - Cualquier aplicación que haga uso de datos externos para crear consultas SQL • puede ser vulnerable sin importar el lenguaje en el que se encuentre escrita. • • • • • • - Las aplicaciones web son más vulnerables debido a: * La mayoría de los sitios web tienen al menos 1 base de datos. * Anonimato del atacante y miles de aplicaciones online. * Ejecución remota y automatizada de ataques. * Aplicaciones de comercio online ( objetivo: tarjetas de crédito ). 7
  8. 8. SQL Injection Cómo funciona un ataque? - Se buscan los puntos de entrada de datos de la aplicación. En web, usualmente • los formularios. • - Deliberadamente se introducen datos incorrectos o posiblemente inesperados. • • • • • • * Letras donde solo números son esperados. * Caracteres de significado especial en sentencias SQL, en especial, comillas. * Texto de longitudes no esperadas. ( Nombre de 500 caracteres? ) * Límites impuestos en el formulario localmente pueden ser excedidos con cURL. - Esperamos errores SQL incorrectamente mostrados junto con el HTML, esto puede • darnos una idea del esquema de la base de datos o de la forma en que los datos del • formulario están siendo usados. • - Usar la información obtenida para intentar inyectar SQL. •
  9. 9. SQL Injection Formas de Protección • - Validar TODOS los datos que ingresan a la base de datos. • - No confiar en datos externos. Los datos externos más comunes son: • • • • * HTTP/GET * HTTP/POST * FileSystem - Estos datos no son confiables, ningún usuario es confiable. • • - register_globals = off, pero eso todo mundo lo sabe, correcto? • - Usa mysql_escape_string, pg_escape_string y similares.. • - Si es posible, utiliza PDO ( PHP Data Objects ) y prepared statements. 9
  10. 10. Code Injection Qué es? - Similar al SQL injection, pero más poderoso, el objetivo es ejecutar código • arbitrario. • - La causa es la incorrecta validación de datos que pueden provenir de fuentes no • confiables. • - Uno de los ataques más conocidos se basa en una funcionalidad de PHP • configurada mediante la directiva allow_url_fopen y allow_url_include. • - Archivos incluidos con include(), include_once(), require_once() son ejecutados • por el intérprete de PHP. • 10
  11. 11. Code Injection Cómo funciona un ataque? • - Se busca la entrada de datos que alimenta la inclusión de un archivo. - Una vez encontrado, se alimenta la inclusión del archivo con un script que • contenga el código que se desea ejecutar. • - Debido a que el código será evaluado en el servidor de la víctima, se adquiere • control completo sobre la aplicación pudiendo inclusive comprometer el servidor. • • - Otro tipo de ataque puede basarse en el constructor de php eval(). 11
  12. 12. Code Injection Formas de Protección - allow_url_fopen = off en php.ini puede ayudar, sin embargo muchas aplicaciones • actuales confian en tener esta directiva habilitada. • - A partir de php 5.2, la directiva allow_url_include fué incluida como una solución • al problema que presentaba allow_url_fopen = off. • • - Validar todos los datos utilizados para incluir y ejecutar archivos. 12
  13. 13. Session Hijacking Qué es? - Es el término utilizado para referirse a un tipo de ataque web en la que el • atacante logra personificarse ante la aplicación web como un usuario que ya • ha iniciado una sesión. • • • - Las aplicaciones web son mas vulnerables debido a que dependen de HTTP, un protocolo sin conciencia de la existencia de sesiones. - HTTP es también un protocolo textual y sin protección alguna de los datos • transmitidos. Cualquier dato puede ser expuesto mediante sniffers como • tcpdump y ethereal. • - Las aplicaciones web usan un session id para identificar una sesión iniciada. • Esto significa que el session id tiene que ser enviado en cada request del • cliente. • - El session id es el objetivo principal de un atacante. Si el session id es conocido, • es muy probable que la sesión pueda ser comprometida. 13 •
  14. 14. Session Hijacking - Flujo del establecimiento de una sesión web con cookies 14
  15. 15. Session Hijacking Cómo funciona un ataque? • - Para secuestrar una sesión se requiere conocer el session id (sessid) • - El session id es transmitido usando cookies o por la URL de las páginas web. • - 3 formas comunes de obtener el sessid son: • • • * Fuerza Bruta * Intercepción * Fixation ( pre-establecimiento de la sesión ) - Fuerza bruta requiere de enviar HTTP request al sitio web con diferentes • sessid's. Algunos de estos sessids pueden ser obtenidos del directorio /tmp • de un hosting compartido. • - La intercepción requiere que el atacante se encuentre en el mismo segmento • de red que la víctima, o en algún punto por el que los paquetes TCP de la víctima • sean ruteados. 15 •
  16. 16. Session Hijacking Cómo funciona un ataque? - El pre-establecimiento del sessid requiere de cierta confianza o ingenuidad • de parte de la víctima ( factores comunmente encontrados ) • - Sniffear el tráfico web de la red en la que se encuentra la víctima. • - Es posible usar ARP spoofing para obligar al switch o al usuario a que sus paquetes pasen por la máquina del atacante. • • - Una vez que el sessid es conocido solo resta hacer un request HTTP con el • sessid obtenido. • - El conocimiento del sessid suele ser suficiente para tomar el control de la • sesión, sin embargo otras protecciones pueden existir. • - Además de obtener el sessid, puede ser requerido conocer algunos datos de • la víctima, como su direcciòn IP. • 16
  17. 17. Session Hijacking Formas de Protección - El pre-establecimiento de sesión puede evitarse habilitando PHP para sólo • usar cookies para la sesión y no aceptarlas por URL. • • - Siempre crear un nuevo session id al recibir los datos de autenticación. - Todas las sesiones deben tener un tiempo de expiración por inactividad y • absoluto. • - La intercepción puede ser evitada utilizando HTTPS ( SSL ) para la conexiones • que requieran ser seguras. • - Los ataques de fuerza bruta y otros ataques basados en el conocimiento de un universo de sessid's pueden ser protegidos guardando los sessid's en una base • de datos utilizando session_set_save_handler(). • • • - Para protección extra se puede crear el session id de acuerdo a la dirección • IP o algún otro dato proveniente del cliente de forma que desde otra dirección • IP o cliente no se pueda utilizar el mismo session id. 17 • •
  18. 18. More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. - Bruce Schneier - Being able to break security doesn't make you a hacker anymore than being able to hotwire cars makes you an automotive engineer. - Eric Raymond - The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - Gene Spafford 18
  19. 19. Referencias. http://www.hardened-php.net/ http://www.php-security.org/ http://blog.php-security.org/ http://www.secunia.com/ 19
  20. 20. Gracias. Moisés Humberto Silva Salmerón http://www.moythreads.com/ moises.silva@gmail.com moyhu@mx1.ibm.com 20

×