Las 10 vulnerabilidades más comunes de Java que debes conocer

Es fácil pensar que el código es seguro. Las vulnerabilidades o posibles exploits es a menudo lo último en lo que piensan los desarrolladores. 

En un mundo donde la velocidad de desarrollo tiene prioridad sobre la seguridad del código, esto puede ser un problema real. Una filtración o un hackeo pueden costarle mucho dinero a una empresa, si no acabar con ella por completo. Según el informe de costo de infracciones de datos 2020 de IBM, el costo total promedio de una infracción se sitúa en 3.86 millones de dólares.

La peor parte de esto es que se tarda un promedio de 280 días en identificar y contener la infracción. Los datos son oro digital y su código es el recipiente que los contiene.

Si bien Java se considera relativamente seguro porque es un lenguaje del lado del servidor, esto no lo hace infalible. Todavía hay varias formas de atacar y acceder a las cosas que deseas que sigan siendo privadas.

Para ayudarte a obtener una ventaja sobre los exploits que pueden atacar tu código, hemos listado las 10 vulnerabilidades de Java más comunes.  También te mostramos cómo puedes (y debes) prevenirlas.

1. Inyecciones de código

Todas las aplicaciones que aceptan entradas son vulnerables a las inyecciones de código. Una inyección de código se produce cuando los datos que pasan a través de la entrada provocan efectos secundarios. Efectos no deseados en la forma en que tu programa se ejecuta o devuelve datos.

Si lo piensas bien, un formulario es un proceso bidireccional. Alguien ingresa los datos, la aplicación retoma los datos y devuelve un resultado. Cuando ese resultado no es el que esperas que sea, sino otra cosa, puedes dejar tu aplicación en un estado vulnerable.

Las inyecciones de código ocurren mucho y son mucho más fáciles de ejecutar de lo que crees. En 2010, un desarrollador japonés notó que podía enviar HTML como tweets. Con un mínimo de JavaScript dentro del HTML, envió un pequeño gusano en Twitter a la medianoche cuando se suponía que nadie estaba realmente despierto.

¿Qué hizo este pequeño fragmento de código?

Cada vez que un usuario pasaba el mouse sobre él, lo retwitteaba instantáneamente. Entonces, cuando uno de tus seguidores se estaba desplazando, podría retuitear ese pequeño gusano. Esto resultó en un efecto en cadena de más de 3000 retuits en unos pocos minutos.

Aunque Twitter no solo usa Java en su conjunto, el evento de advertencia se puede aplicar para proteger tus formularios de entrada.

El método más fácil es aplicar la validación de entrada con limpieza y escaping. Esto significa que cualquier intento de enviar código HTML será analizado o rechazado, dependiendo de lo que esté haciendo tu aplicación.

2. Inyecciones de comando

Una inyección de comandos del sistema operativo, o también conocida comúnmente como inyección de shell, es una vulnerabilidad muy popular. Esta vulnerabilidad permite a los atacantes ejecutar comandos de shell en el servidor que ejecuta tu aplicación.

PHP es a menudo el objetivo de las inyecciones de comandos porque llama a sh/ bash/cmd de forma predeterminada. Java, sin embargo, realiza una bifurcación() del comando dado para crear procesos secundarios y pasarle los argumentos dados.

Sin embargo, esto no garantiza que tu código sea seguro.

Tu aplicación se puede segmentar en diferentes niveles de código heredado unidos para formar el producto final. Estos productos heredados pueden actuar como formas de entrada para inyecciones de comandos de shell.

A veces, es posible que debas enviar una línea de comando a tu servidor, como enviar un correo electrónico de confirmación. En lugar de usar Runtime.exec() para acceder a un servidor, es mejor usar la API de Java disponible ubicada en javax.mail.*

3. Inyección de cadena de conexión

Las cadenas de conexión son un conjunto de definiciones que se utilizan para conectar una aplicación a una fuente de datos. Puedes conectarte a tus bases de datos relacionales, directorios LDAP y archivos.

Para una inyección de cadena de conexión de base de datos, hay cuatro parámetros que un usuario malintencionado necesitaría. La fuente de datos, el catálogo inicial, la identificación de usuario y la contraseña.

Los ataques de cadena de conexión ocurren cuando un hacker obtiene acceso inyectando parámetros en las cadenas de conexión usando punto y coma como separadores.

El problema aquí es que algunos proveedores de bases de datos no tienen límite y se ejecutan en un algoritmo de “last one win“. Esto significa que un atacante puede ejecutar múltiples cadenas de inyección de conexión, dañarlas con parámetros duplicados y la base de datos aceptará la combinación válida.

Como resultado, el atacante termina evadiendo el proceso de autenticación normal sin quedar bloqueado.

Por ejemplo, una cadena de conexión inyectada puede verse así:

Data Source = myDataSource; Initial Catalog = db; Integrated Security = no; User ID = myUsername; Password = XXX; Intergrated Security = true; Data Source = myDataSource; Initial Catalog = db; Integrated Security = no; User ID = myUsername; Password = XXX; Intergrated Security = no;

Una vez dentro, el usuario malintencionado puede secuestrar las credenciales y modificarlas a lo que quiera.

4. Inyección LDAP

Una inyección LDAP aprovecha las validaciones de entrada e inyecta consultas ejecutables. LDAP es el protocolo ligero de acceso a directorios, que es un protocolo abierto y multiplataforma utilizado para la autenticación del servicio de directorio.

LDAP es un lenguaje de comunicación que las aplicaciones pueden utilizar para acceder a los servidores de directorio. Estos servidores de directorio a menudo almacenan nombres de usuario, contraseñas, detalles de cuentas y otra información que se puede compartir en la red.

Las inyecciones de LDAP pueden ocurrir cuando una aplicación inserta entradas no validadas directamente en una declaración LDAP. Cuando esto ocurre, el atacante puede usar la sintaxis del filtro LDAP haciendo que el servidor ejecute otras consultas y declaraciones LDAP.

La forma más sencilla de evadir la inyección de LDAP es asegurarse de que los caracteres especiales de LDAP — ( ) ! | & * son rechazados en la validación.

5. XSS reflejado

Un XSS reflejado, o Cross-site scripting reflejado, es el proceso de agregar scripts maliciosos que se activan a través de un enlace. Luego, la solicitud envía al usuario a otro lugar.

Por ejemplo, un XSS reflejado se puede incrustar para combinar con el resto del sitio en una sección de comentarios de usuario. El usuario puede hacer clic en él y terminar yendo a un sitio de terceros y luego redirigido al sitio original.

Mientras haya un tercero, pueden ocurrir actividades maliciosas como el robo de cookies o sesiones. Aunque es difícil monitorear el XSS reflejado, los filtros de spam en los enlaces enviados pueden ayudar a reducir la frecuencia de ataques.

6. Inyección de recursos

Las inyecciones de recursos ocurren cuando el atacante cambia con éxito los identificadores de recursos utilizados por la aplicación para realizar tareas maliciosas. Esto puede consistir en cambiar el número de puerto, modificar el nombre del archivo y obtener la capacidad de ejecutar o acceder a otros recursos.

¿Cómo puede pasar esto? Por lo general, cuando la aplicación define el recurso a través de la entrada del usuario.

Por ejemplo, imagina que un atacante obtiene acceso a un sitio de compras mediante la inyección de una cadena de conexión o que ha robado con éxito los datos de tu usuario a través de XSS. Ahora puede modificar o consultar detalles mediante la inyección de recursos. Tu atacante puede causar estragos al ordenar cosas desde el sitio, modificar o robar más información sobre tus clientes sin que ellos lo sepan.

7. Inyección SQL

La inyección de SQL es el proceso de inyectar SQL dentro de las solicitudes de datos. Estas dan como resultado que la aplicación de backend devuelva datos confidenciales o ejecute contenido de secuencias de comandos maliciosos en la base de datos.

Esto puede resultar en un compromiso total del host, el acceso a los datos y violaciones de la privacidad. No solo esto, la inyección de SQL puede resultar en la pérdida o corrupción de datos y potencialmente bloquear tu propia base de datos. Cuando esto sucede, la inyección ha tomado el control por completo.

La solución más sencilla para esto es asegurarte de validar en el lado del servidor. Las entradas del frontend se pueden evadir fácilmente y el backend es el tope para evitar que los caracteres no deseados, como espacios y comillas, se filtren.

8. Inyección SQL de segundo orden

La inyección SQL de segundo orden es un proceso de dos pasos. Primero, el atacante agrega algo a tu aplicación, pero no lo ejecuta de inmediato. Es posible que estén esperando más datos o esperando una actividad de activación.

Aquí es donde la inyección SQL de segundo orden difiere de las inyecciones SQL normales.

El atacante inyecta código en la fila de la tabla, que se considera una fuente confiable. Luego se llama a esa fila de la tabla, lo que hace que el ataque pase de su estado inactivo a la ejecución activa.

La prueba de SQL de segundo orden es más difícil debido a su naturaleza a menudo encubierta.

Por ejemplo, el usuario malintencionado se registra con el nombre de usuario ‘o’ hacker ‘=’ hacker

Esto significa que ‘o’ hacker ‘=’ hacker se almacena en la base de datos. La base de datos puede utilizar la siguiente consulta para verificar la identidad de un usuario:

SELECT * from creditcards WHERE username = '<usernamehere>';

Entonces, cuando el nombre de usuario es ‘o’ hacker ‘=’ hacker, la consulta final se parece a esto:

SELECT * from creditcards WHERE username = '' or 'hacker'='hacker';

Luego, cuando ingresa, el nombre de usuario completa la consulta de validación, dando acceso a otros usuarios y tus detalles de cuenta.

9. XSS almacenado

Un ataque XSS almacenado o XSS persistente tiene lugar cuando un atacante inyecta un script en el contenido de un sitio web o aplicación. A diferencia del XSS reflejado, donde se incrustan enlaces de terceros, el XSS almacenado es más peligroso porque no requiere que el usuario interactúe con él.

Los sitios de redes sociales son particularmente vulnerables a los ataques XSS almacenados debido a la naturaleza de la plataforma. Se anima a los usuarios a publicar e interactuar.

XSS también se conoce comúnmente como gusanos web, donde el usuario termina con el elemento ofensivo y se ejecuta en el navegador. Este ataque puede provocar el robo de cookies, información de la cuenta o alguna función adicional a través de la suplantación de la cuenta.

XSS se puede activar en cuatro lugares y, a menudo, se realiza a través de JavaScript: @post.title , post.url , @post.id and @post.footer_attr

Para evitar esto, puede ser útil rechazar o escapar de los caracteres especiales como <> y @ antes de analizarlo.

10. Inyección XPath

Si bien JSON es la estrella en ascenso para la estructuración de datos, los documentos XML siguen siendo populares y se utilizan ampliamente. XPath es la sintaxis utilizada para definir partes de un documento XML. La idea detrás de las inyecciones XPath es similar a las inyecciones SQL.

La única diferencia entre la inyección SQL y XPath es que este último está en formato XML. Este proceso de envío de datos con formato incorrecto se puede lograr fácilmente si el atacante descubre la estructura XML.

Esto permite al atacante navegar por documentos XML, obteniendo acceso a información diversa, como detalles de nombre de usuario y contraseña.

A menudo, se produce una inyección XPath cuando la consulta se basa en entradas no validadas. El truco para prevenir las inyecciones de XPath es utilizar XPath precompilados. Evita tomar expresiones completas de una fuente no segura. Si tienes que parametrizar tu XPath, aíslalo para encadenar solo parámetros para evitar que tu consulta sea secuestrada.

Conclusión

Para la mayoría de las inyecciones, validar las entradas del usuario antes de tomarlas es la forma más sencilla de prevenir posibles ataques. Es fácil transferir la tarea a la interfaz, pero son solo la primera línea de defensa que no siempre te garantiza protección

Si bien Java puede ser frontend y backend simultáneamente, sigue siendo una buena práctica comprobar que lo que sea que te dé el usuario sea lo que esperas. La configuración de tus parámetros de validación puede ser una cuestión de identificar y especificar lo que está permitido. Esto en lugar de tratar de averiguar y eliminar todo lo demás.