¡Buenas! En los posts anteriores de seguridad estuvimos viendo conceptos básicos que habría que saber a la hora de adentrarnos en este mundo para saber cómo protegernos.  Sin embargo, se preguntarán: ¿De qué me tengo que proteger exactamente? ¿Qué pasa si alguien llegase a atacar mi aplicación? 

En este post les explico algunos ataques y/o vulnerabilidades junto con el impacto que pueden llegar a tener en el caso de que sucedan en nuestras aplicaciones.

Inyección de SQL 

Este ataque es uno de los más peligrosos porque permite al atacante: 

• Si se llegase a conocer la especificación de nuestra base de datos (nombres de tablas, columnas, entre otros), visualizar datos afectando la confidencialidad. 
• Manipular, borrar o crear datos nuevos si conoce los tipos de datos de una tabla, impactando en la integridad. 
• Acceder de manera ilegítima al sistema impactando en la autenticación. Si lo combinamos con los puntos anteriores: ¡Podría crear usuarios y conocer las credenciales de los demás! 

¿Cómo se si soy vulnerable a este ataque? Somos vulnerables si tenemos consultas SQL como las siguientes: 

public String obtenerUsuario(String usuario, String clave) {

   String sql = “SELECT * FROM usuario WHERE username= ‘“ + usuario + ”’ AND clave = ‘“ + 
           clave +”’; 

   //...

}

Donde usuario y clave son 2 parámetros que un usuario ingresa en nuestro login. Si no son sanitizados (es decir, limpiar los caracteres especiales en lo que el usuario ingresa), prácticamente podría venir cualquier cosa en estos 2 datos, ¡incluso SQL! 

Si el usuario ingresa: ‘ OR 1=1 ; -- en el campo del usuario, la sentencia SQL, cuando llegue al servidor, se va a ver de la siguiente forma al concatenar los strings: 

SELECT * FROM usuario WHERE username=’’ OR 1=1 --’ AND clave = … 

Observemos paso a paso: 

1. El atacante cerro las comillas de la consulta, haciendo que el where busque un username con un valor vacío, lo cual no traería ningún valor en este caso 

1. Sin embargo, agrega la siguiente condición: OR 1=1, ¿qué significa esto? Que ahora, además de chequear ese username con un valor vacío, va a chequear que 1 sea igual a 1. No se necesita mucha ciencia para saber que eso va a ser siempre verdadero y que me va a traer todos los registros, ¿No? 

1. Luego agrega --, que en SQL es un comentario, por lo que el atacante comenta la parte en la que verifica la clave ingresada (y la comilla simple que está de más) 

¡Y listo! El atacante puede ejecutar SQL arbitrariamente en nuestra base de datos 

¿Cuál es la consecuencia de este ataque? un golpe duro a la aplicación donde podría no solo perderse o filtrarse información, sino también clientes (¿Quién confiaría en una empresa qué no protege sus datos?). 

¿Cómo evito este ataque? 

• A priori, tenemos que desconfiar todo lo que sea ingresado por el usuario, por lo que no podemos usarlo así nomás en nuestro código. Hoy en día muchos frameworks permiten el uso de parameters o alias para SQL en el backend, como Spring, JDBC, etc. 
• Evitar que los mensajes de error de servidor se muestren al frontend, dado que por esta vía se descubre esta vulnerabilidad y otorga información al atacante sobre cómo están compuestas nuestras bases de datos 

Otro punto importante es que si usamos un usuario con permisos sobre todas nuestras bases de datos el atacante puede atacar, además de la de nuestra aplicación, todas las que estén en ese mismo motor de base de datos. 

No solamente puede inyectarse SQL, sino también hay casos de inyección de código por otros medios (Javascript, comandos, etc.), que también son ataques de gran impacto. 

Broken authentication  

Se le dice broken authentication a la acción de obtener las credenciales de un usuario por medio de aplicaciones desarrolladas con malas prácticas de seguridad o con pocas prevenciones relacionadas al manejo de sesiones y cuentas. 

El impacto de este ataque puede variar dependiendo al tipo de usuario que se filtre, podría ser desde un simple usuario con pocos permisos hasta el administrador de una aplicación. 

• Al acceder con la cuenta del usuario, puedo ver su información como tarjetas, números, direcciones, etc. comprometiendo la confidencialidad 
• No solamente puedo ver sus datos, sino que también puedo afectar la integridad de los mismos alterándolos. 

Debajo se listan las malas prácticas que generan estas vulnerabilidades: 

• No usar timeout para las sesiones 
• No volver a crear un Session ID al loguear de nuevo al usuario 
• No limpiar correctamente las cookies de sesión cuando el usuario sale de la aplicación 
• Reescribir las URLs con el ID de sesión 

• No bloquear cuentas cuando fallan una determinada cantidad de veces al loguearse 
• Credenciales muy simples y fáciles de adivinar, como por ejemplo usuario “admin” y clave “admin” 

Estas (y otras) prácticas podrían generar que un atacante ingrese con un usuario que no le pertenece y pueda realizar diferentes acciones según los permisos de la cuenta registrada 

¿Cómo evito este ataque? 

• Administrar timeout para las sesiones 

• Volver a crear los ID de sesión cuando el usuario se vuelve a loguear 
• Evitar usar credenciales fáciles de adivinar por el atacante 
• Manejar los login con el método POST 
• Bloquear usuarios al tener un determinado número de intentos fallidos. 
• No mostrar el session ID del usuario en la vista 

• Si estamos implementando un mecanismo de seguridad propio, verificar que es lo suficientemente robusto 

Hay un montón de métodos más para manejar correctamente las sesiones y la autenticación, un ejemplo de ellos es el uso de códigos de verificación enviados por mail cuando un usuario ingresa desde otro dispositivo a su cuenta. 

Además de estas técnicas, disponemos de frameworks como Oauth 2.0 el cual resuelve gran parte de estas problemáticas. 

XML External Entity (XEE) 

Este ataque es parecido a una inyección de SQL, con la diferencia de que el ataque se da por medio de los parsers XML configurados para procesar entidades externas. Este ataque compromete: 

• La confidencialidad de los archivos del servidor 

• La disponibilidad del servidor, ya que se pueden realizar ataques de Denegación de Servicio por medio de esta vulnerabilidad. 

En XML, las entidades son abreviaciones usadas en el documento, pueden ser usadas en todo el documento e incluso pueden referenciar archivos externos de nuestro sistema. Por ejemplo: 

<!-- ... -->
    <!ENTITY autor "Mario Benedetti."> 

    <!ENTITY titulo "Montevideanos."> 

  

    <!-- Y en nuestro xml los llamamos asi --> 

    <libro>&autor;&titulo;</libro> 

<!-- ... -->

Entonces, un atacante podría ingresar el siguiente DTD en una request (conociendo que el servidor este alojado en un sistema operativo Linux): 

<!-- ... -->

<!DOCTYPE ataque [      

    <!ELEMENT ataque ANY>    

    <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> 

<ataque>&xxe;</ataque> 

<!-- ... -->

¿Qué se hizo en este XML? 

1. Se declara un DOCTYPE llamado ataque 

1. Dentro del mismo, declaramos un tag que se llamará ataque 

1. Declaramos una entity que accederá al archivo especificado. 

1. Por último, escribimos el tag que creamos y dentro, agregamos nuestra entity. 

1. Al enviar este XML, el parser abrirá el archivo que especificamos en nuestra entity 

¿Cuál es el resultado de este proceso? Mostrar los contenidos del archivo passwd dentro del filesystem, el cual tiene los últimos logueos que hubo en el sistema (aunque en las implementaciones más actuales de Linux las claves se encuentran alojadas en otro archivo, con permisos más importantes). 

¿Cómo evito este ataque? 

La manera más segura para evitar este ataque es desactivar el procesamiento de DTDs en nuestros parsers de XML, dado que, en algunos casos en Java, por default vienen configurados para procesar entidades externas. Otras acciones pueden ser 

• Actualizar SOAP a una versión superior a la 1.2 
• Sanitizar los contenidos del XML 

Si usamos JAXB, en este caso no tendremos un flag para desactivar esta configuración, por lo que se debería usar un parser que si tenga esta funcionalidad. 

Por ahora, estos son todos los ataques y vulnerabilidades que vamos a ver en esta publicación. Muchas gracias a OWASP por brindarnos toda la info de estas vulnerabilidades dentro del Reporte Top 10 del 2017