No todas las fugas de datos son iguales. Muchas no son malintencionadas ni son provocadas por un atacante. En este post queremos mostrar que la privacidad está muy ligada a la seguridad de la información que se construye para la página web de cada uno. El relato se hace contando cómo una implementación de servicios externos (publicidad, botones de redes sociales, vídeos, etc.) en sitios web o aplicaciones puede llevar a que terceros que no conocemos se lleven nuestra información personal e incluso las contraseñas de nuestras cuentas.
Para las personas interesadas y que quieran ver el tema en profundidad, publicamos un documento más largo que explica con detalles técnicos este tema que presentamos en la Conferencia RightsCon 2019 en Túnez1.
Invitar extraños a la casa
Decir que “visitamos” un sitio web no da la idea correcta de lo que sucede, pues, en realidad, recibimos la visita del sitio en nuestra casa, que, en este caso, es el navegador o la aplicación que usamos en nuestro dispositivo (computador, celular/móvil, tablet). En el momento en que nos conectamos con el servidor del sitio web, nuestro navegador descarga un código (que incluye pedazos de terceros) que el navegador interpreta y ejecuta. Este código puede aprovechar todas las posibilidades de los protocolos y lenguajes de programación involucrados (HTTP(S), HTML y Javascript en particular). La ejecución de este código genera además flujos de datos en ambos sentidos: de mi dispositivo hacia los servidores web y viceversa. Así, cuando recibimos la visita de un sitio web, éste no viene solo, usualmente trae a sus amigos, y a veces a los amigos de sus amigos.
Esto está vinculado en gran parte con la publicidad. Un sitio web exitoso puede volverse rentable si vende espacios para que otros pongan publicidad en él, tal y como sucede en periódicos y revistas impresas. La diferencia es que, mientras la publicidad impresa está fija, en los sitios web suele ser dinámica. Los anuncios que se muestran cambian dependiendo de quién acceda al contenido. La personalización de la publicidad requiere que se capturen datos de las personas que visitan el sitio.
Los datos de las personas usuarias se pueden capturar de múltiples formas, por ejemplo, el rastreo de los sitios que visitan, o su historial de búsquedas y de videos que miran o los mensajes a los que les dan me gusta.
Las principales compañías que ofrecen servicios gratuitos tienen mecanismos para generar un perfil de sus usuarios con información de sus características, hábitos y gustos. En realidad, cuando se diseña una página o una aplicación y se incluyen servicios de terceros como botones de redes sociales, opciones para compartir, incluso el servicio de búsqueda en el sitio o el de estadísticas de uso, se está incluyendo un código de un tercero que provee un servicio y de paso captura información de quienes visitan la página (esos son los amigos que llevas a la casa de quien navega tu página).
Enseñanzas del análisis de TuLlave y la DIAN
En el laboratorio de privacidad y seguridad digital de Karisma, “K+LAB” hemos hecho varios análisis de sitios webs y de aplicaciones del Estado de manera no intrusiva2, es decir , analizamos los datos públicos del sitio web y de la aplicación y los flujos de datos que se generan en nuestro dispositivo cuando al navegar en sus páginas les pedimos que visiten nuestro navegador (siguiendo la metáfora inicial).
En el caso del sitio web y de la aplicación de la DIAN, encontramos que una mala implementación de servicios de terceros había generado que todos los datos personales que las personas usuarias ingresaban en el formulario de inicio de servicio de chat (nombre, apellido, cédula, teléfono, correo y dirección) le llegaran a Google. Esta información la debería tener solo la DIAN y la empresa contratada para dar el servicio de chat. Por eso, creemos que se trataba de una fuga de información, porque fue la mala implementación de la herramienta de chat la que generaba ese problema.
En el caso del sitio de TuLlave, encontramos un error de implementación similar que enviaba la dirección del correo electrónico del usuario, usada para el inicio de sesión, a todos los terceros presentes en la página: Google, Facebook, Twitter, ShareThis e incluso la empresa de CHAT Emtelco.
Adicionalmente en TuLlave encontramos algo más grave. ShareThis, una empresa estadounidense que ofrece un servicio para compartir contenidos en las redes sociales y que fue instalado en la página para ofrecer esa funcionalidad, capturaba el nombre de usuario y la contraseña que se incluían en el formulario de inicio de sesión. A diferencia del caso anterior, esto no se debía a un error en la implementación del servicio de este tercero, sino a que el código de ShareThis si es muy “goloso” y capta los datos directamente en los campos del formulario, incluso antes de su envío al destinatario legítimo. ShareThis construye bases de datos con la información que toma de las páginas que instalan su servicio. Estas bases de datos luego las comparte y/o vende a terceros3 lo que sirve, por ejemplo, para alimentar el sistema de perfilamiento de las personas en internet para publicidad.
Para nosotros esto podría ser particularmente preocupante porque:
- ShareThis no estaba autorizado a recibir esa información. El correo y la contraseña son datos que sólo debería tener los responsables del sitio web TuLlave (Recaudo Bogotá).
- ShareThis captura datos de sus usuarios para comercializarlos. En sus términos y condiciones de uso indica que puede compartir los datos con sus aliados pero no se sabe quiénes son ni qué comparten.
- En Julio del 2018 ShareThis sufrió un incidente de seguridad grave en el cual se robaron datos de más de 41 millones de usuarios, incluyendo correos, fechas de nacimiento y las huellas de contraseñas. Estos datos se vendieron en el 2019 en el mercado negro.4
Afortunadamente, como mencionamos, los responsables del sitio web de Tullave atendieron nuestro informe y desactivaron los formularios en donde se observaba este problema.
Qué podemos hacer
Como personas usuarias de internet, más allá de las recomendaciones habituales de no llenar formularios en páginas que no son seguras, es conveniente -aunque no sea práctico porque puede frenar la navegación-, usar extensiones que bloquean los códigos de terceros cuando navegamos, como NoScript.
Como desarrolladores de sitios web o aplicaciones. Debemos ser mucho más concientes del rol que jugamos en el ecosistema y la forma como podemos evitar o facilitar que los datos de nuestros usuarios sean recogidos. Por ejemplo: realizar un análisis de la confianza que merecen los terceros que te ofrecen servicios para tu página web y evaluar los riesgos de incluir su código para las prestaciones de la página que desarrollas. Incluso ponderar dónde se requiere realmente incluir servicios de terceros. Todo desarrollador debería hacerse preguntas como: ¿realmente todas las páginas del sitio web necesitan una herramienta de estadísticas de uso? ¿Toda información debe incluir botones de compartir en redes sociales?Otras recomendaciones de carácter técnico se pueden consultar en el documento que detalla a profundidad estos casos.
Acá puedes encontrar el informe completo.
1. Detecting personal dataleaks to third party actors, RightsCon 2019,https://rightscon2019.sched.com/event/Pvwj/tech-demos-blowing-the-whistle-data-leaks-and-digital-dropboxes.
2. Más detalles sobre el tipo de análisis y nuestra perspectiva para la mejora de la seguridad digital con metodologías abiertas y replicables: https://web.karisma.org.co/analisis-de-imeicolombia-com-co-cronologia-de-un-dialogo-con-el-gobierno/ y aquí: https://karisma.org.co/la-corresponsabilidad-en-accion/
3. Según la política de privacidad de la empresa, a “editores, anunciantes, clientes y socios de datos”, https://sharethis.com/es/privacy/
4. Ver el artículo de Wikipedia y la página de la compañía en la cual anuncia el incidente de seguridad: https://en.wikipedia.org/wiki/ShareThis y https://sharethis.com/data-privacy-incident/