Tag Archives: Web

Restricciones de seguridad en una aplicación WEB J2EE

Los descriptores de las restricciones de seguridad de una aplicación WEB son detallados en el web.xml (descriptor de despliegue).

Están formados por:
1) Una colección de recursos WEB (patrones URL y metodos HTTP).

<url-pattern>: indica el contexto dentro de la aplicación web que se verá afectada por la restricción.
<http-method>: indica los métodos que se ven afectados por la restricción.
<http-method-omission>: Indica que metodos HTTP aplican la restricción excluyendo a todos los demás.
2) Restricción de acceso por roles:

<role-name>: Nombre del rol al que afecta la restricción.

3) Restricciones sobre los datos de usuario y su transporte.

<transport-guarantee>: Define la protección de datos que lleva el transporte.

  • CONFIDENTIAL: all user data must be encrypted by the transport (typically using SSL/TLS).
  • NONE: no protection of user data must be performed by the transport.

 

Ej de configuraciones:

1) Acceso público a parte de una aplicación (sin restricción de acceso): recursos que son de ámbito publico en la WEB.

 

2) Restricción de Acceso por ROL: Operaciones sobre recursos que sólo son accesibles a los usuarios de un rol determinado.

3) Denegar el acceso http a todos los metodos salvo al GET y POST.

NOTA: Métodos del protocolo HTTP: HEAD, GET, POST, PUT, DELETE y TRACE.

Autenticación mútua basada en certificados

El uso de certificados es un método extendido dentro del mundo de la web y las aplicaciones cliente/servidor para crear conexiones seguras vía SSL y para autenticar/autentificar quién está detras de cada extremo de la conexión.

Un aplicación de los certificados es su uso para realizar una autenticación mútua entre un cliente y un servidor. Esto permite:

- Establecer una conexión segura ya que al contar el lado servidor con un par de claves, que será el origen de su certificado, puede también establecer una conexión segura vía SSL.

- Autenticar, no solo el lado servidor de la conexión, es decir, a que se está conectando el cliente, si no también autenticar al cliente, desde el punto de vista del servidor. Esto aumentará la seguridad del lado servidor, permitiendo el acceso solo a aquellos cliente que cuenten con el certificado deseado.

Los pasos para implementar una autenticación mútua con certificados usando el servidor de aplicaciones Tomcat y la herramienta de generación de claves y certificados de Java keytool, presente en cualquier JDK, son los siguientes:

1. Si aún no se tiene, se crea el almacén de claves del servidor con su par de claves correspondiente:

 

2. Se exporta el certificado del servidor a partir del par de claves anteriormente creado:

 

3. Se añade el certificado del servidor al almacén de claves que usa el cliente desde la aplicación que emplea para conectar al servidor:

 

4.  Creamos un nuevo par de claves para el cliente:

Almacenamos el par de claves como de tipo PKCS12 para poder importar posteriormente otros certificados de cliente generados a partir de los navegadores web.

5. Generamos el certificado del cliente:

 

6. Añadimos al almacén de claves del servidor el certificado del cliente que queremos autenticar:

 

7. Si aún no se ha relizado, se configura Tomcat para que use la conexión segura vía SSL:

En el fichero de configuración de Tomcat <TOMCAT_HOME>\conf\server.xml se descomenta el conector definido para SSL. Además se añaden la ruta al almacén de claves del servidor y el password para acceder al mismo.

Se reinicia Tomcat.

8. Se ha de crear el usuario y rol asociados al cliente a autenticar. Esto se puede realizar de diferentes maneras y usando distintos mecanismos de autenticación y autorización de usuarios con los que cuenta Tomcat. El más sencillo de todos es el uso del fichero de usuarios de Tomcat. Si se opta por este mecanismo, los pasos a seguir son los siguientes:

Editar en el fichero de usuarios de Tomcat (<TOMCAT_HOME\conf\>tomcat-users.xml) y añadir al mismo el rol y el usuario autenticado con el certificado anteriormente importado. Por ejemplo:

La cadena incluida como username ha de ser exactamente el conjunto de valores que se usaron para crear el par de claves del cliente. Reiniciar Tomcat para que los cambios tengan efecto.

9. Por último, en el descriptor de la aplicación web del lado servidor se ha de configurar la restricción de seguridad que dara pie a la autenticación mediante certificados. Para ello, se edita el fichero WEB-INF/web.xml y se incluye, dentro de la etiqueta principal de web-app lo siguiente:

Mediante la configuración anterior se indica lo siguiente:

<url-pattern>/MainServlet</url-pattern> – indica el contexto dentro de la aplicación web que se verá afectada por la restricción.

<http-method/> – se especifica que métodos HTTP se autenticarán.

<role-name>cliente</role-name> – es el nombre del rol al que se le permite el acceso.

<transport-guarantee>CONFIDENTIAL</transport-guarantee> – indica que el acceso ha de ser vía HTTPS de forma obligatoria.

<auth-method>CLIENT-CERT</auth-method> – activa el método de autenticación por certificado.

10. Las pruebas:

Las pruebas de autenticación pueden ser realizadas bien desde un navegador web que intente acceder a la URL servidora protegida o bien con una aplicación de cliente, como un cliente HTTP(S).

- Navegador Web

Sería necesario importar el certificado del cliente al mismo. Una vez hecho esto, basta con intentar acceder a la URL que se quiere testear. Si la autenticación es validad, se accederá sin problemas, si no el navegador indicará el error.

- Cliente HTTP(S)

Ha de importar ámbos certificados, el de cliente y el de servidor, en el almacén de claves que use la aplicación. Si la aplicación está implementada en Java, se puede usar el almacén de claves por defecto de la JVM, que se encuentra en <JAVA_HOME>\ jre\lib\security\cacerts.

Cómo crear WARs usando el JAR de JDK

Se pueden extraer y crear ficheros de despliegue de tipo WAR y EAR desde la línea de comandos, usando la funcionalidad jar del JDK de Java.

1. Crear un WAR

$ jar cvfm war_deploy.war META-INF/MANIFEST.M img/ index.html WEB-INF/

2. Extraer un WAR

$ jar xvf war_deploye.war

Para los EARs funcionaría exactamente igual.