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.

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

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

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