Jaime Carmona LoechesIngeniero Informático Superior por la UAM

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2010-11-29

Tutorial visitado 3.684 veces Descargar en PDF

JCAPTCHA: ANÁLISIS TÉCNICO EN APLICATIVOS REALES

Jaime Carmona Loeches

Introducción

Este tutorial es continuación del anterior tutorial publicado donde se explicaron los principios básicos de JCaptcha y una configuración inicial en el framework Struts.

En este segundo tutorial, que pretende ser conciso y directo, vamos a ver en qué casos es conveniente utilizar JCaptcha dentro de un aplicativo web y en cuáles puede suponer un coste innecesario, teniendo en cuenta una gráfica bidireccional que valore y estime los parámetros: coste de desarrollo, accesibilidad, y seguridad informática.

Desarrollo

Posibles consecuencias de un ataque automático

Lo primero que debemos tener en cuenta es que JCaptcha es un filtro de ataques automáticos masivos a un ordenador.

La pregunta lógica es, ¿qué consecuencias tendrían estos ataques?

Por orden de gravedad estimada por el autor, las consecuencias pueden ser las siguientes:

-Gravedad media: Saturación del servidor e indisponibilidad por un período de tiempo. Costes indirectos son una bajada de la imagen del aplicativo, pérdida de usuarios, pérdida de credibilidad...

-Gravedad alta: Acceso automático y malicioso a herramientas propias del aplicativo, como Bases de Datos, y posibilidad de perder datos, o bien tener datos erróneos. Si el aplicativo no tiene una política de backup, puede sufrir pérdidas de datos difíciles de recuperar.

Cada aplicativo persigue su propia finalidad, por lo que siempre es bueno medir las consecuencias del error en función del aplicativo concreto.


Análisis en aplicativos reales

Para ello, imaginemos un escenario y dos aplicativos web, dentro de una empresa, para analizar la implementación de JCaptcha en pantallas específicas, con el fin de prevenir ataques externos.


SISTEMA A:

Sistema orientado a la Intranet de una empresa, con un número medio de usuarios.

Las pantallas relativas a formularios, donde el usuario puede lanzar datos y peticiones al servidor, son las siguientes:

-LOGIN: El usuario puede loguearse a la aplicación, que está visible para todos los trabajadores de la empresa.

Imaginemos que la empresa tiene trabajadores internos, dentro de los cuales para un grupo de ellos está destinado el aplicativo, y trabajadores externos.

A esta pantalla pueden acceder un número de usuarios bastante elevado que no tienen relación con el aplicativo.

-REGISTRO: El usuario puede enviar datos para registrarse. Después de una primera pantalla, se envía un email al usuario, desde el cual puede acceder a una segunda pantalla de registro.

-PANTALLA PRINCIPAL (requiere loguearse): Una vez logueado dentro del sistema, existen diferentes pantallas con formularios de operaciones de lectura y escritura.

Notas a tener en cuenta:

-Dentro de esta aplicación, que no es visible a priori desde fuera de la empresa, existe un número de trabajadores que pueden hacer un uso malicioso de la aplicación, intentando saturarla, así como los propios usuarios de la misma por razones que pueden ser desconocidas inicialmente.

-En la pantalla de login inicial, el acceso no está controlado, por lo que podríamos sufrir un ataque masivo con facilidad.

Las consecuencias de este ataque estarían relacionadas con:

1) El alto número de peticiones simultáneas (y saturación del servidor)

2) Operaciones de lectura contra la Base de Datos o LDAP interno, relacionados con el logueo del aplicativo

-En la pantalla inicial de registro, el caso es similar. Sin embargo, en la segunda pantalla, el usuario ha especificado un email, por lo que configurar un ataque automático en estas condiciones tiene un nivel mayor de dificultad.

Además, en esta pantalla hay un acceso de escritura contra base de datos, por lo que las consecuencias podrían ser más peligrosas.

-Una vez que el usuario entra dentro del aplicativo, el sistema ya tiene constancia del usuario que se ha introducido, por lo que a priori sería poco adecuado lanzar un ataque automático (por decirlo de otra manera, no sería muy inteligente por el atacante).

Después de este primer análisis, las decisiones que se toman son las siguientes:

-Introducir JCaptcha en la pantalla de Login y la pantalla inicial de Registro.

-Ignorar la introducción de JCaptcha en la segunda pantalla de Registro y en la pantalla Principal.


SISTEMA B:

Sistema orientado publicado en la WWW, accesible para toda persona con conexión a Internet.

Las pantallas específicas son las siguientes:

-LOGIN: El usuario puede loguearse a la aplicación, esta pantalla es visible para cualquier persona con conexión a Internet

-REGISTRO: El usuario puede enviar datos para registrarse. Esta pantalla es visible para cualquier persona con conexión a Internet y, a diferencia del aplicativo anterior, consta de una sola pantalla.

-PANTALLA PRINCIPAL (requiere loguearse): Una vez logueado dentro del sistema, existen diferentes pantallas con formularios de operaciones de lectura y escritura.

Notas a tener en cuenta:

Dentro de esta aplicación, que es visible a un número mayor de usuarios, con la dificultad de rastrear los ataques en internet, el nivel de seguridad a priori debe ser mayor. Para ello, se toman las siguientes deciones:

-En la pantalla de login inicial, el acceso no está controlado, por lo que podríamos sufrir un ataque masivo con facilidad.

-En la pantalla de registro, el caso es similar. Además, en este caso la operación contra la base de datos no es sólo de lectura, si no que es de escritura, por lo que los daños del ataque pueden ser de mayor consideración.

-Una vez que el usuario entra dentro del aplicativo, el sistema ya tiene constancia del usuario que se ha introducido, por lo que a priori sería poco adecuado lanzar un ataque automático (por decirlo de otra manera, no sería muy inteligente por el atacante, o bien requeriría un nivel de habilidad mucho más avanzado).


Conclusiones

JCaptcha nos ayuda a dificultar los ataques automáticos a nuestros aplicativos web, donde es conveniente analizar su uso teniendo factores como los siguientes:

-Usuarios a los que son accesibles a la web.

-Número potencial de los mismos.

-Consecuencias de los ataques, como saturación del servidor y posible corrupción de datos.

-Incremento de la dificultad de la accesibilidad del aplicativo, así como el tiempo de desarrollo.

A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL: