• Java en castellano
• Java Hispano
• Java SUN
• SUN español

• IBM JAVA
• Jakarta Apache
• Java ABOUT
• Java Community Process
• Java NET
• Java O'Reilly
• Java ONE
• Java SUN
• Java World
• ONJAVA
• Oracle & Java
• SUN
• The Server Side

• Diseño
• E-learning
• Flash
• Linux
• Multimedia
• Ofimática
• PHP

Desarrollo de aplicaciones Web seguras con Java

Índice:

1. Desarrollo de aplicaciones Web seguras
a. Tipos de ataques
i. Ataques anónimos
ii. Ataques a la integridad
iii. Ataques de denegación de servicio
b. Mecanismos de autenticación
i. HTTP Basic
ii. HTTP Digest
iii. HTTP Client
iv. Basado en formularios HTML

2. Implementación de los mecanismos de seguridad en el Tomcat
a. Los dominios de seguridad
b. Dominios basados en el archivo tomcat-users.xml
c. Configuración en el web.xml

3. Protección de los recursos en el Tomcat

4. Resumen

Desarrollo de aplicaciones Web seguras con Java

Muchas empresas ya están aprovechando los sistemas Internet para exponer sus operaciones a sus clientes. Actualmente, millones de personas utilizan diferentes tipos de sistemas de información basados en la tecnología Web por la facilidad de acceso que ésta ofrece. La mayoría de empresas, como las bancarias y compañías de comercialización, tienen ahora presencia online, por ejemplo, las agencias bancarias permiten realizar transacciones monetarias, pago de servicios y otras operaciones más. Sin embargo, estas aplicaciones que son de comercio electrónico no podrían darse de ninguna manera sin tener en cuenta la seguridad.

En este artículo veremos el mecanismo de seguridad robusto que nos ofrece la plataforma Java.

Tipos de ataques

Todas las empresas que expongan sus servicios a Internet tendrán que proteger muy cuidadosamente su información y recursos. Desde luego que existen sistemas más críticos que otros, digamos, los bancos tendrán que prestar más atención en estos temas de la seguridad porque la información que maneja es monetaria y no faltará más de una persona hábil en informática que quiera ganar dinero fácil. Pero en general, todas las aplicaciones Web deben estar resguardadas y aseguradas ante cualquier tipo de ataque.

Ya que las aplicaciones Web son globalmente públicas pueden ser atacadas libremente. Una aplicación Web puede ser atacada por diferentes motivos y personas. Digamos, un hacker puede atacar por diversión, o quizás un empleado despedido quiera tomar venganza, o un ladrón profesional quiera atacar con algún fin específico.

Generalmente, podemos hablar de 3 tipos de ataques:

• Ataques anónimos. Este tipo de ataques tratan de obtener información confidencial analizando (sniffing) las comunicaciones entre 2 PC’s. Una manera de prevenir este tipo de ataques es encriptando los datos que son transmitidos. Por ejemplo, es común que las instituciones financieras utilicen el protocolo HTTPS para su aplicación Web online.
• Ataques a la integridad. Este tipo de ataques altera la información en tránsito con fines maliciosos. Se puede evitar esto usando técnicas de autenticación eficientes, como criptografía de llaves públicas.
• Ataques de denegación de servicios. Intenta inundar a un sistema de falsas peticiones, y eso ocasiona que el sistema aparezca como no disponible para peticiones legítimas. Esto se previene usando firewalls que bloquean el tráfico de red en puertos no utilizados.

Otros tipos de ataques van referidos a:

• Autenticación, se da con el ya conocido LOGIN; usuario y contraseña.
• Autorización, se refiere a lo que el usuario puede hacer en el sistema luego de haber sido autenticado.
• Integridad de los datos, se refiere a que si el usuario hace algún tipo de operación dentro del sistema, este no debe ser saboteado o cambiado.
• Confidencialidad, se refiere a que sólo el usuario indicado debe acceder a la información sensible. La diferencia con Autorización es que la confidencialidad asegura que incluso si la información cae en malos manos, esta sea inutilizable.

La especificación de los Servlets proporciona métodos para implementar la seguridad en las aplicaciones Web.

Mecanismos de autenticación

Ahora que ya vimos algo de las seguridad en las aplicaciones Web, veremos cómo los Servlets implementan la autenticación. Existen 4 mecanismos:

1. HTTP Basic
2. HTTP Digest
3. HTTPS Client
4. Autenticación HTTP basada en formularios

Los 4 mecanismos están basados en el usuario y contraseña, y el servidor Web mantiene la lista de usuarios y contraseñas.

HTTP Basic
Es simple y es el más usado para proteger los recursos. Consta de una ventana pop up que pide el usuario y contraseña. El problema es que no encripta los datos y no se puede modificar (personalizar) la ventana pop up.

HTTP Digest
Es muy parecido al HTTP Basic, sólo que este mecanismo sí es encriptado (usa MD5). Lo malo es que sólo lo soporta Internet Explorer, y tampoco lo soportan todos los contenedores de servlets.

HTTPS Client
Se trata del HTTP sobre SSL (Secure Socket Layer). Los datos que viajan entre el servidor y el cliente son encriptados usando la criptografía de llave pública. Es en definitiva el más seguro y es soportado por la mayoría de los navegadores. Las desventajas son que requiere un certificado de una autoridad certificadora como Verisign, y además, es muy costoso su implementación y mantenimiento.

Autenticación HTTP basada en formularios
Es un similar a HTTP Basic pero utiliza un formulario en HTML para ingresar el usuario y contraseña. Es fácil de implementar y todos los navegadores lo soportan. Lo malo es que no es seguro (los datos no viajan encriptados), y además se requiere que los clientes soporten cookies.

Implementación de los mecanismos de seguridad en el Tomcat

El servidor Tomcat define un modelo de seguridad basado en roles. Bajo este modelo un usuario siempre estará asignado al menos a un rol y los permisos se le otorgarán al rol en lugar de al usuario. Esto da flexibilidad al modelo porque podemos tener muchos usuarios desempeñando el mismo rol, como también es posible que un usuario desempeñe varios roles, teniendo como permisos la suma de todos los roles.

Los dominios de seguridad

Un dominio de seguridad es un mecanismo del Tomcat que se usa para proteger los recursos de la aplicación Web (JSP’s, Servlet’s, directorios, gráficos, páginas HTML, etc.). Esto nos da la capacidad de proteger un recurso con una restricción de seguridad predeterminada y luego definir qué roles pueden acceder al recurso protegido.

La interfase del Tomcat que hace posible esta funcionalidad es el org.apache.catalina.Realm. Esta proporciona un mecanismo a través del cual la lista de usuarios, contraseñas y roles pueden ser integrados al Tomcat.

El Tomcat implementa 2 tipos de dominios de seguridad:

• Basado en el archivo tomcat-users.xml
• Basado en alguna fuente JDBC

En ambos casos, la configuración del mecanismo de seguridad se realiza en el web.xml de la aplicación Web. La diferencia está en el origen de dónde se obtienen los usuarios, contraseñas y roles. En el primer caso, los usuarios autorizados para ingresar a nuestra aplicación se guardarán en el archivo DIRECTORIO_TOMCAT/conf/tomcat-users.xml. Y en el segundo caso, serán obtenidos de una base de datos.

Dominios basados en el archivo tomcat-users.xml

Por defecto, éste archivo lo tendremos así:

En el archivo tenemos a 3 usuarios: “tomcat”, “role1” y “both” que tienen como contraseña “tomcat”. Además tenemos un tercer atributo que es roles. El valor que tenga este atributo es muy importante porque los permisos están basados en ROLES y no en los usuarios. Y esto da bastante flexibilidad en la administración de la seguridad.

Para dar un ejemplo, crearemos 2 usuarios más:

El usuario Juan es programador, y el usuario David es programador y además analista.

Y para que funcione todo esto deberemos hacer algo más en el Tomcat. Abrir el archivo DIRECTORIO_TOMCAT/conf/server.xml y descomentar la siguiente línea:

Al descomentar esa línea estamos habilitando el dominio basado en el archivo tomcat-users.xml como implementación por defecto para todo el contenedor. Si no encontramos esta línea deberemos agregarla directamente bajo el elemento

.

Configuración en el web.xml

Agregaremos un par de líneas en el descriptor de despliegue de nuestra aplicación Web, se trata del elemento , el cual tiene la siguiente estructura:

Veamos los sub-elementos:

• . Determina cual de los 4 métodos de autenticación (BASIC, DIGEST, HTTPS, FORM) va a ser usado para validar a los usuarios.

• . Determina el nombre del domino de seguridad que va a ser usado. Esto solo sirve para el método BASIC.

• . Determina la URL de la página de login y también se determina la URL de la página de error en caso de fallar el login. Este elemento es usado sólo si el método de autenticación es FORM, en los otros casos, esto es ignorado.

Por ejemplo, una simple autenticación BASIC:

	
		BASIC
		Intranet
	

En cambio, si utilizamos el mecanismo de autenticación FORM, entonces necesitamos escribir 2 páginas HTML: la primera de login (donde el usuario ingresa su usuario y contraseña) y la segunda de error si el login falla. Sería algo así:

...

FORM


/login.html
/login_error.html


...

Y el login.html podría ser así:

Ingrese sus datos:

Y el login_error.html:

Nombre de usuario y/o contraseña incorrectos.

Protección de los recursos en el Tomcat

Aún no hemos terminado, necesitamos configurar qué recursos vamos a proteger y cuáles serán los roles permitidos.

Hasta este momento, todos los recursos de la aplicación Web son accesibles para todo el mundo. Para restringir el acceso a los recursos tenemos que identificar lo siguiente:

• Autorización de los recursos por roles: Recordemos que la autorización en el sistema se dará por roles y no por usuario. Por lo tanto hay que agrupar a los usuarios por roles. Por ejemplo, el AnalistasServlet debería estar accesible para los usuarios que tengan el rol de analista.
• Tipo de transporte: Esto es si la petición viaja por HTTP o HTTPS.

Pues vamos a configurar estas 3 cosas en el descriptor de despliegue de la aplicación Web usando el elemento . Veamos un ejemplo:

...


	Proyecto de Desarrollo


Intranet Analistas

/servlet/AnalistasServlet/*
/analistas/*

POST
GET



analista



NONE




FORM


/login.html
/login_error.html




analista

...

Este es el fragmento del archivo web.xml que nos interesa para entender cómo el Tomcat protege sus recursos. Veremos uno a uno los elementos del

:

• : Este elemento es opcional, especifica el nombre de la restricción de seguridad para identificarla de otras que puedan haber.

• : Define los recursos que protegeremos. Podemos tener varios de estos elementos dentro de un . A su ves, el elemento está compuesto de 4 elementos:

  • : Define el nombre del recurso.

  • : Define una descripción del recurso. Opcional.

  • : Define la URL del recurso. Podemos especificar muchos de estos elementos para diferentes recursos, como servlets o directorios.

  • : Proporciona el tipo de requerimiento HTTP.

• : Define los roles que pueden acceder a los recursos especificados en el
  . Contiene:

  • : Descripción

  • : Define el rol que puede acceder a los recursos. Debe ser un nombre que está definido en el elemento del mismo descriptor de despliegue. En el web.xml que hemos visto se están aceptando todos los usuarios que tengan como rol analista. Recordar que el nombre del rol debe coincidir con el nombre que hemos configurado en el archivo tomcat-users.xml (donde a su ves están las contraseñas)

• : Define la forma como los datos se transferirán entre el cliente y el servidor. Contiene los siguientes elementos:
  • : Descripción (opcional)
  • : Contiene uno de los siguientes valores: CONFIDENTIAL, INTEGRAL o NONE. El NONE indica que la aplicación no necesita ninguna garantía de integridad o confidencialidad de los datos que son transmitidos. CONFIDENTIAL y INTEGRAL indican que la aplicación requiere confidencialidad e integridad, respectivamente. Usualmente, HTTP es usado cuando este elemento está en NONE, y HTTPS cuando está configurado en CONFIDENTIAL o INTEGRAL.

  Además, vemos que estamos utilizando un mecanismo de autenticación FORM, es decir usando formularios en HTML.

  Y finalmente tenemos al elemento

  , que define los roles que pueden ser usados en el
  . Recordemos que el Tomcat verificará el usuario, contraseña y rol del archivo tomcat-users.xml.

  Resumen

  Conforme las empresas vayan exponiendo sus negocios en Internet, la seguridad será un tema cada vez más importante. En este artículo vimos acerca de los tipos de ataques que sufren las aplicaciones Web, los mecanismos de seguridad que existen para salvaguardar los datos que viajan por la Web y también cómo implementar estos mecanismos con las herramientas y servicios que proporciona el servidor Tomcat.