Autenticación insuficiente

Acciones para las que el usuario no tiene privilegios, pero que por medio de un atajo puede hacer

Ejemplo

En este ejemplo vamos a coger la pantalla de edición de un mensaje, en principio sólo el usuario que escribio ese mensaje debería poder acceder a él.

Resultado

Vemos como en otro navegador que no comparte las mismas cookies se puede acceder a la edición del mensaje sin ningún problema

Solución

La solución a este problema es la comprobación de que las acciones que no se pueden ejecutar por otros usuarios esten bien autenticadas

Html Injection

Inyección de código HTML dentro de una página de tal modo que este sea ejecutado como tal

¿Por qué puede suceder?

Una mala gestión de las etiquetas HTML dentro de una página web que afecten a campos donde sea posible introducir texto

Pongamos un ejemplo sencillo

Supongamos que encontramos un foro y queremos verificar si es vulnerable ante este tipo de ataques, una forma es introducir una sencilla línea HTML

Éxito

Si nos apareciera el mensaje como en este caso el sitio sería vulnerable

Ataques mas serios

¿Que pasaría si introdujeramos mil veces <br /> ?

También podemos introducir scripts tal como veremos en la siguiente sección

Soluciones

Dos formas sencillas de evitar esto es eliminando y/o desactivando las etiquetas

strip_tags() = Elimina las etiquetas

htmlentities() = Obtiene las etiquetas de la inyeccion pero no las ejecuta

XSS

Cross Site Scripting

Inyección de código de scripting para que sea ejecutado por el navegador del cliente

Dos tipos

• Reflejado: Cuando este es pasado como un parámetro entre diferentes vistas
• Persistente: Cuando este queda guardado en una base de datos y siempre va a ejecutarse

Ejemplo

Vamos a usar XSS de tipo persistente en el foro para ver la información de las cookies

Resultado

El resultado puede no parecer maligno pero podríamos usar esta prueba para hacer ataques más sofisticados

Solución

• Filtrar los datos de entrada, sobre todo los que contengan < ó >
• Para formatear texto usar otros recursos que no sean código html
• Uso de librerías anti-XSS

Sniffing

Escuchas ilegales de la red

Ejemplo

Vamos a ver un ejemplo de Sniffing en el foro. Nos registraremos cómo administrador y después utilizaremos un programa de escucha, a ver que pasa.

Resultado

Como podemos comprobar no tenemos ningún problema en hacernos con la contraseña del administrador.

Solución

Sql Injection

Inyección de código SQL de manera que las consultas muestren datos que no deberían

Ejemplo

String consulta = "Select * from Users where username='"+ userInput +"' and password='"+ passInput +"';

¿Y si inyectamos un poco de SQL?

Resultado: Suplantación de identidad

Select * from Users where username=' 'OR 1=1;

Otros posibles usos

• Entrar como administrador -> admin'; --
• Borrado de datos -> 'DROP TABLE USERS; --

Solución

Uso de PreparedStatement en Java

Select * from user where username = ? and password = ?

CSRF

Cross Site Request Forgery

Forzar o engañar a un usuario autentificado a realizar acciones que no desea

Ejemplo

Lori envía una aparentemente inofensiva imágen al Administrador haciendo uso de los mensajes del foro

Resultado

El Administrador, un poco ingénuo, hace click en la imagen. Pero... ¡No es oro todo lo que reluce!

Consecuencia

El administrador sin saberlo, y puede que no se haya dado cuenta, ha desactivado la cuenta de Rick.

A Lori no le caía bien Rick :(

Solución

• Uso de librerias para intentar mitigar los ataques CSRF
• Ejemplo: OWASP CSRFGuard 3.0

Buenas prácticas

Logs

El uso de librerías de logs es altamente recomendado. Nos permiten saber la interacción de los usuarios con el sistema, además de los errores que se puedan haber producido:

• Simple Logging Facade for Java (SLF4J)
• Apache log4j
• java.util.logging

Validar campos de los formularios

Es una buena práctica con la que evitaremos posibles futuros errores y agujeros de seguridad.

Quitar mensajes de error informativos

No se debe mostrar más información de la necesaria, por lo tanto los errores descriptivos no deberían ser mostrados al usuario

También tenemos que tener especial cuidado con los comentarios en el código.

Quitar u ocultar archivos que no deberían ser accedidos

Archivos como configuraciones de la base de datos, logs u otros archivos de configuración no deberían poder ser accedidos para ello se deben sacar fuera del directorio de la web u ocultarlos.

También podemos configurar el servidor para servir solo algunos tipos de fichero. En el caso del foro, con ficheros HTML e imágenes, debería ser suficiente.

Ocultación de rutas privadas

Puede interesarnos que ciertos rutas no salgan en los buscadores:

Ficheros como robots.txt nos permite que los buscadores no indexen estas páginas: Robots.txt EpiGijón

¡CUIDADO! Esto no hace que no se pueda entrar, por lo tanto no nos exime de tomar medidas de seguridad complementarias

Vigilar JSP

Debemos tener en cuenta las vulnerabilidades que puedan existir en JSP. Hay que estar al tanto de nuevos exploits y tener siempre actualizado el sistema