Vulnerabilidades en Aplicaciones Web PHP
Descargar como PPT, PDF1 recomendación3,654 vistas
Este documento presenta una introducción a las vulnerabilidades comunes en aplicaciones web desarrolladas en PHP, incluyendo inyección SQL, inyección de código y secuestro de sesiones. Explica brevemente cómo funcionan estos ataques y formas de protegerse, como validar todos los datos de entrada, usar prepared statements en PHP, y configurar sesiones para evitar su fijación.
Vulnerabilidades en Aplicaciones Web PHP
- 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. 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. 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. Estadísticas - Crecimiento de PHP Fuente: http://www.netcraft.com/Survey/ 4
- 5. - Servicios de red más usados Fuente: http://www.securityseer.com/ 5
- 6. - Top 10 de vulnerabilidades web Fuente: http://www.owasp.org/ 6
- 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. 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. 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. 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. 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. 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. 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. Session Hijacking - Flujo del establecimiento de una sesión web con cookies 14
- 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. 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. 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. 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
- 20. Gracias. Moisés Humberto Silva Salmerón http://www.moythreads.com/ moises.silva@gmail.com moyhu@mx1.ibm.com 20