Vulnerabilidades en Aplicaciones Web PHP CIISA 2007 “ You can't consider the problem of defense without first understanding the problem of attack ” - Doug.

Presentación del tema: "Vulnerabilidades en Aplicaciones Web PHP CIISA 2007 “ You can't consider the problem of defense without first understanding the problem of attack ” - Doug."— Transcripción de la presentación:

1 Vulnerabilidades en Aplicaciones Web PHP CIISA 2007 “ You can't consider the problem of defense without first understanding the problem of attack ” - Doug Tygar - Moisés H. Silva 1

2 Agenda 2. SQL Injection * Qué es? * Cómo Atacar? * Cómo Protegerme? 3. Code Injection * Qué es? * Cómo Atacar? * Cómo Protegerme? 4. Session Hijacking * Qué es? * Cómo Atacar? * Cómo Protegerme? 1. Vulnerabilidades en PHP * PHP, lenguaje inseguro? * Estadísticas 2

3  - 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. PHP, Lenguaje Inseguro? 3

4 Estadísticas Fuente: http://www.netcraft.com/Survey/ - Crecimiento de PHP 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  - 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 ). Qué es? 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. 8

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

19 Referencias. http://www.hardened-php.net/ http://www.php-security.org/ http://blog.php-security.org/ http://www.secunia.com/ 19

20 Moisés Humberto Silva Salmerón http://www.moythreads.comhttp://www.moythreads.com/ moises.silva@gmail.com moyhu@mx1.ibm.com Gracias. 20