Bitacora WarNov.com

Bitácora de WarNov.com online: Para evitar tropiezos en desarrollos con Silverlight 3, WCF y otras novedades: http://warnov.com/bitacora.htm

Google Ofrece IE8?

Iba a publicar esto como un tweet. Pero se justifica de sobremanera escribir algo más detallado del asunto.
Un amigo tenía problemas con la visualización de un sitio que creó, al verlo con “IE8” lo pongo entre comillas, porque supuestamente era la versión estable. Cuando fui a revisar el sitio, la renderización que apreció fue perfecta usando el RTM de IE8. Entonces le pregunté por la versión que usó, y noté que no era el RTM. Así que buscando un link para dárselo y que bajara la versión final, me encontré con un link (abajo lo encuentran) en el que se ofrecía la descarga de IE8 desde el dominio de Google.

Sí! Un link para descargar IE8 desde Google!
Muchos dirán: “Qué es esto de por Dios” o “WTF”

El “valor agregado” que da Google (o que obtiene?) al ofrecer IE8, es que lo ofrece optimizado para trabajar con Google:

1. Home: Google personalizable
2. Motor de búsqueda predeterminado es Google
3. Aceleradores para blogs, email y demás, están ajustados para trabajar con sus productos
   a. Blogspot
   b. Google Maps
   c. Gmail
4. La barra de Google viene preinstalada

Para mí esto significa:

1. A Google le gustó IE8: No van a ofrecer algo en contra de su imagen general (Además tienen su propio Browser!)
2. Las islas tecnológicas son totalmente inviables
3. Los buenos productos giran alrededor de sus clientes y no de sus creadores

Hoy en día los modelos de producto abierto están a la orden. El mismo IE8 permite usar cualquier buscador (Kumo, Google, tú mismo podrías crear el buscador de tu predilección en minutos). Los aceleradores permiten escoger el operador de tu predilección para las acciones disponibles, los WebSlices se basan en estándares completamente abiertos…

Y no solo pasa con el Browser. Silverlight es el ejemplo cumbre de la apertura que están teniendo tecnologías que otrora estaban encerradas dentro de una sola corporación. Un usuario con Firefox desde Unix podría bien hacer un request a un servidor Apache que interpreta un PHP que escribe XAML (la aplicación Silverlight como tal) con inyección de datos desde MySQL, para ver en una interfaz tridimensional con audio y video los mejores momentos de la última válida Nascar (el ejemplo va en concordancia con el amigo que me inspiró este post) más las estadísticas de la carrera, en una espectacular aplicación Silverlight con tecnología Microsoft.

Un pequeño apunte aquí: Han notado por ejemplo que los sitios principales de las nuevas tecnologías Microsoft ya no son .com sino .net?

Ya es muy conocido hoy en día que la diferencia que puede marcar un producto contra su competencia, es la capacidad de ofrecer valor agregado a sus usuarios.

Y en tecnología, con la gran cantidad de opciones que hay, este valor agregado se ofrece mediante:

1. La capacidad de integración, para que aquellos acostumbrados a un producto puedan comenzar a usar otro nuevo sin tener que olvidarse de lo que ya saben; de lo que les gusta; de lo que les da dinero.
2. La capacidad de aceptar los errores, aprender de ellos e implementar soluciones que muchas veces resultan mejores que las ofrecidas por la competencia que anteriormente usaba estos defectos como factores diferenciadores y definitivos.
   

IE8 para mí, cumple perfectamente con estas dos premisas sin las cuales, un producto bien puede estar despidiéndose de su market share. Hoy en día me siento seguro hablando de él sin temor a que saquen la innumerable lista negra de otros tiempos.

Más información en inglés y descarga, desde aquí

Nota: Este post pertenece a mi nuevo blog que está en construcción y que incluirá Silverlight con posibilidades de Reply y demás: warnov.com

Evitando abuso en sitios web

Alternativas para evitar abuso de los portales

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.

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, cosa poco ideal, pues hoy en día 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 costos 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. Como se observa luego de la investigación y entrevista con el proveedor de infraestructura, 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. 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. Pero ya hemos visto que esto no es conveniente dadas las condiciones de negocio actuales. 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 tal como se hace con las estadísticas actualmente.