Seguridad en aplicaciones Web Java

INTRODUCCIÓN

Java es uno de los lenguajes de programación más utilizados a nivel empresarial a la hora de desarrollar aplicaciones de gestión con buenos niveles de escalabilidad y disponibilidad. Requiere programadores con sólidos conocimientos en programación orientada a objetos y arquitectura de software. En este curso se enseñan los principales criterios y buenas prácticas desde el punto de vista de la seguridad a la hora de crear aplicaciones web con Java.

OBJETIVOS DEL LIBRO

Dar a conocer los principales criterios y buenas prácticas para crear aplicaciones web de forma segura en Java.

Comentar los aspectos de seguridad en las diferentes etapas del desarrollo de aplicaciones web en Java, alineadas a las buenas prácticas propuestas por OWASP.

Diseñar y desarrollar aplicaciones en entornos web, utilizando la especificación Java Enterprise Edition (J2EE), mediante el uso de librerías y herramientas que podemos encontrar dentro del ecosistema de Java.

1

VULNERABILIDADES EN APLICACIONES WEB DEL PROYECTO OWASP TOP TEN EN JAVA

INTRODUCCIÓN

OWASP es una comunidad abierta dedicada a facilitar que las organizaciones puedan desarrollar, adquirir, operar y mantener aplicaciones en las que se pueda confiar. El Top Ten de OWASP representa un amplio consenso sobre cuáles son los fallos más críticos de la seguridad de aplicaciones web.

El origen de las vulnerabilidades puede estar en cualquier componente involucrado en el sistema de producción de una aplicación web, como servidores, seguridad de redes y conexiones, accesos a sistemas relacionados, etc. Sin embargo, muchas de ellas pueden prevenirse escribiendo código fuente seguro y protegido contra amenazas potenciales.

OBJETIVOS DE LA UNIDAD DIDÁCTICA

Analizar la importancia de la seguridad en aplicaciones de comercio electrónico.

Dar a conocer el proyecto OWASP (Open Web Application Security Project) y en particular el top ten de vulnerabilidades que podemos encontrar en aplicaciones web.

Dar a conocer las principales vulnerabilidades en el contexto de una aplicación en Java y ofrecer soluciones para mitigarlas.

1.1 INYECCIÓN

1.1.1 Introducción

Los defectos de inyección, como los de inyección de SQL, sistema operativo y LDAP, se producen cuando se mandan datos no confiables a un intérprete como parte de un comando o una consulta. Los datos que envía el atacante pueden engañar a la aplicación para ejecutar comandos no intencionados o acceso a los datos sin la debida autorización.

1.1.2 Inyección SQL

Un ataque de Inyección SQL consiste en la inserción de código SQL por medio de los datos de entrada desde la parte del cliente hacia la aplicación. Es decir, por medio de la inserción de este código el atacante puede modificar las consultar originales que debe realizar la aplicación y ejecutar otras totalmente distintas con la intención de acceder a la herramienta, obtener información de alguna de las tablas o borrar los datos almacenados.

Como consecuencias de estos ataques y dependiendo de los privilegios que tenga el usuario de la base de datos bajo el que se ejecutan las consultas, se podría acceder no solo a las tablas relacionadas con la aplicación, sino también a otras tablas pertenecientes a otras bases de datos alojadas en ese mismo servidor.

Entre los principales problemas que pueden causar los ataques de Inyección SQL podemos destacar:

Confidencialidad. De forma habitual, las bases de datos almacenan información sensible, por lo que la pérdida de confiabilidad es un problema muy frecuente en aquellos sitios que son vulnerables a este tipo de ataques.

Autenticación. Si el sistema de login que se utiliza para acceder a una zona restringida de una web es débil, por medio de este tipo de ataques se podría acceder sin la necesidad de conocer ni el usuario ni la contraseña.

Integridad. Al igual que un ataque por inyección SQL permite leer información relevante almacenada en la base de datos, también es posible realizar cambios o incluso borrar toda información mediante este tipo de vulnerabilidad.

Hablamos de pruebas de Inyección SQL cuando intentamos inyectar una determinada consulta SQL directamente en la Base de Datos, sin que la aplicación haga una validación adecuada de los datos.

Un ejemplo clásico de la inyección SQL consiste en pasar la entrada de un usuario directamente al intérprete, sin validarla a través de consultas generadas dinámicamente. El siguiente ejemplo muestra código vulnerable a la Inyección SQL:

String consulta = "SELECT id_usuario FROM datos_usuario WHERE

nombre_usuario = ‘ + req.getParameter(usuario) + ’ and

password_usuario = ‘ + req.getParameter(password) +’";

Código Java Vulnerable al Ataque de Inyección SQL

Si no se validan correctamente los parámetros usuario y password, el usuario podría registrarse con la expresión ‘) OR ‘1’=’1’ como nombre de usuario y contraseña. En este caso se le permitirá siempre el acceso ya que la segunda condición de esta expresión es siempre cierta.

1.1.3 Precedencia de operadores

El operador AND (Y) toma precedencia sobre el operador OR (o), y la operación AND solo es VERDADERO si ambos valores son VERDADERO. En este caso, ambos valores son FALSO, por lo que terminamos con la siguiente operación:

El operador OR es VERDADERO si cualquiera de los dos operandos es VERDADERO, así que en este caso el resultado de todas las operaciones condicionales es un simple VERDADERO para cada registro, haciendo que esto actúe como una petición select sin una condición. Y una operación select sin una condición nos devolvería todos los registros de la tabla.

1.1.4 Particularidades de los backends

Entre las bases de datos susceptibles a este tipo de ataques nos encontramos MySQL, Oracle, Postgres o MS SQL.

Este punto detalla algunos de los objetivos más interesantes a la hora de realizar un ataque contra algunas de las bases de datos más populares. Se trata de conocer las principales tablas a las que intentar extraer información acerca de los permisos de los que dispone el usuario con el que está interactuando el aplicativo con la base de datos, las principales tablas de las que extraer información interesante y cómo conocer la estructura y el contenido de la misma.

1.1.4.1 MYSQL

Algunas de las funciones de MySQL más interesantes son:

version(): Muestra la versión de la base de datos.

database(): El nombre de la base de datos a la que se está conectado.

user(), system_user(), session_user(), current_user(): Nombres de distintos usuarios.

last_insert_id(): Devuelve el identificador de la última inserción.

connection_id(): Devuelve el identificador de la conexión actual.

En cuanto a las tablas, lo mejor es consultar los manuales más actualizados, ya que los catálogos cambian con cierta frecuencia. Esta información se puede encontrar en:

http://dev.mysql.com/doc/refman/4.1/en/

http://dev.mysql.com/doc/refman/5.0/en/

En la versión 5, las tablas más interesantes que se encuentran en el catálogo o esquema de base de datos son:

Tables: información acerca de las tablas almacenadas.

Columns: los campos que componen las tablas.

Views: vistas disponibles.

User_privileges: permisos de los que disponen los usuarios.

Routines: almacena procedimientos y funciones.

Con la siguiente consulta se obtienen todas las tablas del catálogo:

SELECT table_schema,table_name FROM information_schema.tables WHERE table_schema != ‘mysql’ AND table_schema != ‘information_schema’

En el siguiente enlace se pueden ver todas las consultas que se pueden realizar relacionadas con MySQL:

http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injectioncheat-sheet

1.1.4.2 ORACLE Y DB2

Oracle tiene una tabla llamada dual que permite realizar cualquier tipo de consulta contra ella, aunque no tiene ningún contenido. Se trata de una tabla comodín que se utiliza para realizar consultas sobre variables de entornos o hacer pruebas respecto a la estructura de la consulta sobre la que se realiza la inyección.

En cuanto a información técnica sobre la base de datos, se puede obtener la versión de la misma mediante cualquiera de las siguientes consultas:

SELECT version from instance;

SELECT banner from v$version;

En cuanto a la estructura de la base de datos, se pueden obtener las tablas mediante una consulta a la tabla "all_tables. Para consultar las tablas a las que tiene acceso el usuario, se puede añadir la condición where owner=user. El nombre de las mismas se encuentra en la columna table_name".

Con las siguientes consultas se obtienen todas las tablas del catálogo:

SELECT table_name FROM all_tables;

SELECT owner, table_name FROM all_tables;

En el siguiente enlace se pueden ver todas las consultas que se pueden realizar relacionadas con Oracle:

http://pentestmonkey.net/cheat-sheet/sql-injection/oracle-sql-injectioncheat-sheet

Base de datos DB2

Se trata de una de las bases de datos más veteranas, aunque tal vez es de las menos comunes en entornos de aplicaciones web. Normalmente se encuentra en entornos de mainframe en los que no hay un acceso desde el exterior. Aun así, en ocasiones es posible encontrarla en dichos entornos y realizar ataques de inyección SQL. A continuación, se muestran algunas de las tablas más interesantes para consultar en un ataque de este estilo:

sysibm.sysdummy1: Esta tabla se utiliza como comodín para realizar consultas, es equivalente a la tabla dual en Oracle.

sysibm.systables: Nos da información sobre las tablas que contiene la base de datos.

sysibm.views: Información respecto a vistas.

sysibm.columns / sysibm.syscolumns: Campos de las tablas.

sysibm.usernames: Información de usuarios para conexiones externas.

sysibm.sysversions: Contiene la versión de la base de datos.

En cuanto a los usuarios, DB2 siempre utiliza un sistema externo para la autenticación, por lo que no encontraremos información respecto de los mismos en las tablas de catálogo.

Con la siguiente consulta se obtienen todas las tablas del catálogo:

SELECT name from sysibm.systables;

En el siguiente enlace se pueden ver todas las consultas que se pueden realizar relacionadas con DB2:

http://pentestmonkey.net/cheat-sheet/sql-injection/db2-sql-injection-cheatsheet

1.1.4.3 POSTGRESQL

Las siguientes consultas permiten obtener el usuario que esté logueado:

SELECT user

SELECT current_user

SELECT session_user

SELECT usename FROM pg_user

SELECT getpgusername()

En cuanto a información técnica sobre la base de datos, se puede obtener la versión y el nombre de la base de datos actual mediante las siguientes consultas:

SELECT version()

SELECT current_database()

Con la siguiente consulta se obtienen todas las tablas del catálogo:

SELECT c.relname FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN (‘r’,") AND n.nspname NOT IN (‘pg_catalog’, ‘pg_toast’) AND pg_catalog.pg_table_is_visible(c.oid)

En el siguiente enlace se pueden ver todas las consultas que se pueden realizar relacionadas con PostgresSQL.

http://pentestmonkey.net/cheat-sheet/sql-injection/postgres-sql-injectioncheat-sheet

1.1.4.4 SQL SERVER

Las tablas más importantes de las que se puede obtener información del sistema se encuentran dentro de la base de datos máster. Algunas interesantes son:

sysobjects: Contiene información acerca de todos los objetos dados de alta por el catálogo, donde se encuentran los nombres de tablas, vistas, procedimientos almacenados, etc.

syscolumns: Contiene la lista de las columnas de todas las tablas.

sysusers: Información acerca de los usuarios que tiene el sistema, incluyendo el hash de la contraseña de acceso. En caso de conseguir el acceso, sería posible descargar dicho hash para intentar ataques de fuerza bruta con los que obtener la contraseña en claro.

sysdatabases: Contiene información acerca de otras bases de datos que se encuentran en el catálogo, de modo que se puede ampliar el ataque a las mismas.

Finalmente, un punto especialmente interesante en cuanto a esta base de datos son los procedimientos que ofrece para la interacción directa con el sistema operativo. A continuación, se listan algunas de las funciones más interesantes desde el punto de vista del atacante.

xp_cmdshell: Ejecuta un comando directamente contra el sistema operativo.

sp_makewebtask: Crea un fichero html que contiene el resultado de una consulta, lo cual es especialmente recomendable para el envío posterior de la salida de la misma, o publicarlo directamente en caso de ser posible por la infraestructura de la base de datos.

sp_addextendedproc: Crea un stored procedure. Útil para la creación de backdoors o para intentar escalar privilegios en la base de datos sobre la que se gana acceso, así como para realizar tareas automáticas.

xp_dirtree: Lista todas las subcarpetas de un directorio. Indicado para conocer la estructura de la máquina que hospeda la base de datos.

xp_fixeddrives: Lista las unidades de disco.

xp_servicecontrol: Permite arrancar y parar servicios. Muy útil para, por ejemplo, arrancar un servicio de ftp con el que interactuar con la máquina.

Con la siguiente consulta se obtienen todas las tablas del catálogo:

SELECT name from sysibm.systables;

En el siguiente enlace se pueden ver todas las consultas que se pueden realizar relacionadas con SQL Server:

http://pentestmonkey.net/cheat-sheet/sql-injection/mssql-sql-injectioncheat-sheet

1.1.4.5 USO DE CHEATSHEETS

Es aconsejable consultar las Cheat Sheets de OWASP, como guías de referencia para garantizar la seguridad de las aplicaciones.

El Cheat Sheet almacenamiento de contraseñas comenta cómo se deben almacenar las contraseñas de forma segura a efectos de autenticación de un usuario.

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

El Cheat Sheet prevención de XSS comenta cómo prevenir esta vulnerabilidad desde el punto de vista del desarrollador.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_ Cheat_Sheet

El Cheat Sheet olvido de contraseña es una guía que ayuda a los desarrolladores a crear la funcionalidad de recuperar la contraseña de forma segura.

https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

El Cheat Sheet gestión de la sesión es una guía donde se describen las consideraciones de seguridad necesarias cuando se utilizan mecanismos de gestión de sesión en aplicaciones web.

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

El Cheat Sheet sql inyection comenta cómo prevenir esta vulnerabilidad desde el punto de vista del desarrollador.

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

El Cheat Sheet de autenticación es una guía donde se describen las consideraciones de seguridad necesarias cuando se utilizan mecanismos inicio de sesión y de autenticación en aplicaciones web.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

El Cheat Sheet de parametrización de consultas es una guía donde se describen las consideraciones de seguridad necesarias para crear aplicaciones resistentes a una inyección SQL.

https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet

1.1.5 Contramedidas generales

Las contramedidas en este punto van destinadas a verificar que el código no es vulnerable a una inyección SQL. Para ello a nivel de código es recomendable seguir las siguientes recomendaciones:

Emplear consultas parametrizadas (Prepared statements): consiste en separar la compilación de la consulta de su ejecución con los parámetros indicados. Son sentencias precompiladas, en las cuáles se indica qué parámetros serán ingresados por el usuario. De esta forma podemos indicarle al DBMS cuál es el código a ejecutar y cuáles serán las variables. Esto permite que el motor distinga la sentencia a ejecutar de los datos de entrada y así evitar que el usuario agregue sentencias SQL. Cuando se construye la sentencia sql, el motor de BD analiza, compila y optimiza la forma en que se va a ejecutar, de forma que, si la construimos una vez y la ejecutamos n veces, el tiempo de ejecución puede disminuir considerablemente.

Por ejemplo, un código SQL inyectado que no conforme un dato del tipo esperado (cadena, entero, real, fecha) provocará un fallo/excepción.

Para hacer una consulta con un PreparedStatement lo primero que se hace es indicar la estructura de la consulta dejando los parámetros marcados con una interrogación ? y posteriormente se irá indicando que son cada una de esas interrogaciones y su tipo de dato. Como podemos ver la consulta se construye de otra forma utilizando el carácter de interrogación ? para definir la posición de cada uno de los parámetros.

PreparedStatement stmt =connection.prepareStatement(SELECT * FROM users +WHERE USERNAME = ? AND PASSWD = ?);

stmt.setString(1, username);

stmt.setString(2, passwd);

ResultSet results = stmt.executeQuery();

Emplear procedimientos almacenados ya que generalmente nos les afectan las inyecciones SQL. Si se diseñan de forma adecuada, no hay posibilidad de generar dinámicamente consultas SQL maliciosas.

Emplear frameworks del tipo ORM (Object Relational Mapping). En Java encontramos herramientas como Hibernate y JPA (Java Persistence API). Suelen ofrecer su propio lenguaje de consultas y por defecto hacen uso por defecto de consultas parametrizadas.

Escapar los datos introducidos por el usuario: La idea es que cada vez que el usuario ingrese datos que se utilizarán en una sentencia, se escapen los caracteres especiales (comillas simples, dobles, barras invertidas) para que el dato sea un solo string y el motor de BD no la confunda por el código a ejecutar.

Escapar los caracteres especiales utilizados en las consultas SQL: Al hablar de escapar caracteres estamos haciendo referencia a añadir la barra invertida \" delante de las cadenas utilizadas en las consultas SQL para evitar que estas corrompan la consulta. Algunos de estos caracteres especiales que es aconsejable escapar son las comillas dobles (), las comillas simples (‘) o los caracteres \x00 o \x1a ya que son considerados como peligrosos pues pueden ser utilizados durante los ataques.

Asignar mínimos privilegios al usuario que conectará con la base de datos: El usuario que utilicemos para conectarnos a la base de datos desde nuestro código debe tener los privilegios justos para realizar las acciones que necesitemos. No utilizar nunca un usuario root ya que de esta forma estaremos dando facilidades a un posible atacante.

1.2 PÉRDIDA DE AUTENTICACIÓN Y GESTIÓN DE SESIONES

1.2.1 Introducción

Las funcionalidades relacionadas con la autenticación y gestión de sesiones de los usuarios son frecuentemente implementadas de forma incorrecta, permitiendo a los atacantes comprometer contraseñas, llaves, token de sesiones, o explotar otros fallos de implementación para suplantar la identidad de otros