Uno de los principales riesgos en la operación de nuestros portales es su posible abuso por parte de terceros que con el fin de hacerse a la base de datos que los alimentan, están en capacidad de ejecutar todas las consultas que a bien tengan, tanto manual como automáticamente. En este artículo me estaré enfocando en ambientes sin manejo de sesión y autorización que son los más vulnerables a este tipo de anomalías.

Los portales son muy vulnerables a estos abusos (que no se pueden catalogar realmente como “ataques”) dado que la naturaleza del negocio implica que todas las consultas estén abiertas a todos los públicos y no con menos importancia, a los motores de búsqueda; de manera que no existen mecanismos de autenticación que impidan por ejemplo el acceso al sitio por medio de robots o programas que extraen automáticamente el contenido de nuestros sitios; además existen efectos colaterales como disminución del ancho de banda y de velocidad de proceso en los sitios.
Existen básicamente dos tipos de acciones que podrían ayudar a mitigar este riesgo. El primer tipo comprende las acciones ejecutadas a nivel de la infraestructura de la aplicación. El segundo tipo consiste en las acciones ejecutadas a nivel de desarrollos adicionales en la aplicación como tal.

Infraestructura
Existen servidores de seguridad que reciben todas las peticiones de los clientes antes de que estas lleguen a la aplicación como tal. Esta herramientas se instalan al frente de los servidores web. Y ayudan a través de los siguientes mecanismos:

Cookies
Las cookies estarían almacenando la cantidad de requests que está haciendo cada cliente en una unidad de tiempo dada. Esto requiere sin embargo que se exija a todos los clientes el uso de cookies; hay que tener en cuenta sin embargo, que existen muchos usuarios que desactivan estas cookies en sus browsers.

Javascript
El uso de javascript permite generar rutinas que los robots no podrían seguir, de manera que el acceso quedaría restringido a estos entes automatizados. La gran contra que tiene este enfoque, es que puede requerir procesos de considerable costo en el servidor. Además que se le estaría restringiendo el uso también a motores de búsqueda como google que usan robots para obtener información de los sitios.


Aplicación
A nivel de aplicación el conjunto de acciones posibles es más diverso. Se trata de rutinas destinadas a detectar accesos irregulares a la aplicación. Estas pueden ser provistas como productos terminados ya hechas por terceros, o como desarrollos nuevos dentro de la aplicación.

Delay
Existen herramientas como ISTools de Peter Blum, que basadas en un patrón de IP (esto puede ser contraproducente en el caso de que las ips reales estén siendo reemplazadas por las ips de los ISP) detectan los accesos irregulares y generan retardos en las respuestas, advertencias y finalmente denegación del servicio a los supuestos atacantes. Un caso favorable es que en algunas ocasiones los ISP mantienen la ip de sus clientes y la reenvían como una variable HTTP que puede ser consultada. Pero esto no ocurre siempre.

Javascript y Cookies
Ambos mecanismos funcionan con desarrollos de productos de igual forma a la que fue descrita en el apartado de infraestructura.

Listado de Robots
Herramientas de terceros permiten consultar un IP dada y verificar si ha sido tildada como un robot para en ese caso tomar acciones al respecto.

Cómo obtener la solución al problema
Para generar una solución se han de tener en cuenta los siguientes puntos:
  1. Hoy en día no hay una solución ad-hoc que abarque todo el problema sobretodo sin efectos colaterales.
  2. Para generar una solución es muy necesario comenzar por definir unas políticas de detección de abuso que permitan establecer los parámetros para las herramientas que se usaran/construirán
  3. Los mayores problemas se presentan cuando no es posible obligar la autenticación en los portales luego no hay manejo de sesión
  4. Existen ISPs que direccionan los requerimientos con una IP única
  5. Existen usuarios que no permiten el uso de cookies en sus máquinas
Teniendo en cuenta lo anterior, se puede sugerir implementar una solución compuesta tal como se describe a continuación:

  1. Definir la política de uso abusivo (Esto implica declarar cuándo se considera que se está extrayendo información del sitio de manera inescrupulosa; por ejemplo, que un mismo usuario visite más de 50 páginas de resultados de una misma búsqueda, o que realice más de 20 búsquedas distintas en un determinado lapso de tiempo)
  2. Definir las acciones a tomar luego de la violación de la política. (Redireccionar a un captcha, denegar el servicio, retardar el servicio, etc.)
  3. Proveer un mecanismo que permita avisar acerca de la violación de la política de acceso. Dependiendo de lo elaborado de la política, esto puede ser ejecutado desde la infraestructura o de la aplicación. Una política sencilla como solo contar el número de requests de una ip dada se puede implementar en la infraestructura. Una política algo más completa como la descrita como ejemplo en el numeral 1, requiere de un a implementación en el lado de la aplicación.
  4. Implementar e integrar los puntos anteriores de manera que cuando el mecanismo de advertencia avise acerca de un posible abuso de acuerdo a las políticas definidas, se tomen las acciones pertinentes.

Recomendaciones acerca de la política de abuso

Un acceso abusivo siempre puede ser detectado cuando desde una misma IP son hechos muchos requests. Pero esto mismo puede suceder con el caso de los ISP que tienen una sola ip de salida. Para evitar tachar incorrectamente a los ISP es necesario verificar el tipo de requests que se están haciendo desde una ip sospechosa. En general las consultas sobre los sitios no abarcan más de 10 páginas de resultados de un mismo tema. También de acuerdo a las estadísticas se puede establecer un límite para distintas búsquedas en un tiempo dado por una ip dada; por ejemplo más de 100 búsquedas distintas en 10 minutos indicarían un comportamiento malicioso.

Entonces ante una violación a la política establecida anteriormente se garantizaría que no se cae en el falso positivo del ISP así que ante este comportamiento sospechoso se podría iniciar con buscar la IP en una base de datos provista por un tercero en la que están registrados los robots en la actualidad. Si este filtro pasa, se continúa con la verificación de si se trata de un robot autorizado como el de google o yahoo; esto se logra a través de un DNS lookup reverso. Aquí entonces si no pasa la validación, se procederá con la acción correctiva.

Como inconveniente a esta solución, se cita la complejidad de su desarrollo, ya que requiere hacerse del lado de la aplicación que al no tener manejo de sesión, requeriría una implementación con almacenamiento en base de datos por ejemplo.