Sobre el diseño de formularios seguros en HTML

Mesa de trabajo En How to Build HTML Forms Right: Security otro resumen de los que estamos trayendo últimamente. En este caso, sobre cómo preparar formularios en HTML teniendo en cuenta la seguridad.

Cifrado, la diferencia entre GET y POST (más visible o menos visible, pero también otras), spam, honeypots, mecanismos basados en retos, APIs, cortafuegos de aplicaciones, validación de datos (siempre en el servidor), saneamiento de datos …, tokens, CSRF, y otros elementos más infraestructurales.

Un buen repaso.

Un ejemplo de interacción insegura entre sistemas seguros: YouTube

Espectación audiovisual Hacer un sistema invulnerable es muy difícil. Hay personas muy ingeniosas que encontrarán formas de ir consiguiendo lo que quieren. En Stealing Your Private YouTube Videos, One Frame at a Time David Schütz nos cuenta sus experimentos para tratar de ver vídeos privados del sitio. Estos vídeos son los que sólo puede ver el propietario o personas a las que se les de permiso de manera explícita.

… and Private, where only you can watch the video, or other accounts you’ve explicitly given permission to do so.

Después de intentarlo directamente, pensó que podría tratar de probar con otros servicios de Google, de forma que a través de ellos pudiera saltarse las protecciones (el típico caso en el que una herramienta confía en otra, más de lo que debería).

A great thing to do in a situation like this, is to try to look for other products/services which are not your main target, but are somehow interacting with its resources internally. If they have access to its resources, it might be possible that they don’t have every level of protection that the main product has.

Y entre ellos encontró el servicio de anuncios (Ads) que, efectivamente, accede a los vídeos para poder seleccionar en qué momento es mejor mostrar la publicidad.

It had an embedded player, some statistics, and an interesting feature called Moments. It allowed advertisers to “mark” specific moments of the video, to see when different things happen (such as the timestamp of when the company logo appears).

Siguiendo con la investigación descubrió una llamada para ver el pantallazo de un momento determinado.

Looking at the proxy logs, every time I “marked a moment”, a POST request was made to a /GetThumbnails endpoint, with a body which included a video ID:

La prueba, entonces, era evidente: poner allí el identificador de un vídeo ‘privado’ y ver qué sucedía (pista: devolvía el pantallazo).

I did what I did a bunch of times already, and replaced the ID to my second account’s Private video in the request, and to my surprise, it returned a base64 response!

Esto sólo es un pantallazo, claro, pero con esa información ver el vídeo completo es relativemente sencillo. Sólo hay que descargar una imagen cada 33 milisegundos del vídeo en cuestión.

So I just have to download every image starting from 0 milliseconds, incrementing by 33 milliseconds every time, and then construct some kind of video using all of the images I have acquired.

Interesante, aunque seguro que todos están pensando que hace falta el identificador del vídeo (el mundo es imperfecto). Además, nos dice, no podremos escuchar el sonido y la resolución no será muy buena.

In the real world you would have to know the ID of the target video. Mass-leaking those would be considered a bug on its own.

Since these are just images, you can’t access audio.

The resolution is very low. (but it’s high enough to see what is happening)

En todo caso, desde el punto de vista de la seguridad, logro conseguido. Y recordatorio de una vieja lección: sistemas seguros pueden interactuar entre sí de forma no tan segura. Y darle algún beneficio al atacante.

The takeaway from this bug is that situations where two different products interact with each other under the hood are always a good area to focus on, since both product teams probably only know their own systems best, and might miss important details when working with a different product’s resources.

Una historia interesante.

Los robots que navegan por la web y nuestra privacidad

Telégrafos En Extracting Personal Information from Large Language Models Like GPT-2 un recordatorio de que todo lo que ponemos en internet puede ser leído por alguien y, en consecuencia, no podemos contar con que no se sabrá.

Se refiere al modelo GPT-2 que trata de generar párrafos de texto coherentes entrenando a una inteligencia artificial con datos obtenidos de internet.

We’ve trained a large-scale unsupervised language model which generates coherent paragraphs of text, …

Cuando se usan esas cantidades de datos es difícil validar todo lo que hay allí y, por lo tanto, a veces se utilizan datos que pueden tener información que algunas personas considerarían delicada.

These extracted examples include (public) personally identifiable information (names, phone numbers, and email addresses), IRC conversations, code, and 128-bit UUIDs. Our attack is possible even though each of the above sequences are included in just one document in the training data.

La privacidad dejó de existir hace algún tiempo y este estudio es una pieza más en la demostración. Podemos pensar en prohibir, censurar,… Pero siempre habrá alguien con capacidad de hacerlo y mostrarlo (como es el caso) o pasar desapercibido porque nadie pueda mirarlo.

Los coches y la divulgación de datos personales

Coche de D. João V Hacía mucho que no hablábamos de la seguridad (informática) de los coches. Hace algunas semanas leía Insecure wheels: Police turn to car data to destroy suspects’ alibis y me pareció interesante para comentarlo aquí.

En general, no somos muy conscientes de la falta de conocimiento sobre ello que tenemos ni tampoco de la falta de seguridad de los sisstemas de entretenimiento e información de los vehículos. Lo que el vehículo puede registrar, por ejemplo.

the relative lack of public awareness about and lack of security in vehicle infotainment systems

Esto se complica con las capacidades cada vez mayores, con mejores y más sensores, lo que todavía genera más información.

As automobiles become more automated, with self-parking and other “smart” features, they need more sophisticated sensors and computers, which means autos of the future will collect even more data, digital forensic and privacy experts say.

Todo ello puede, en un momento dado, ayudar a resolver un crimen. Pero también puede ayudar a cometerlo.

Just as the trove of data can be helpful for solving crimes, it can also be used to commit them

Y no parece haber (o no está muy claro) leyes que determinen los datos que el vehículo puede conservar. Ni lo que el fabricante hará con ellos.

No federal laws regulate what automakers can collect or do with the vast majority of our driving data.

No es raro tampoco adquirir un vehículo (o para el caso, cualquier dispositivo) y que contenga datos de sus ‘vidas anteriores’.

… each of the modules he bought had “owner’s home and work location, all saved Wi-Fi passwords, calendar entries from the phone, call lists and address books from paired phones, Netflix and other stored session cookies.”

De hecho, enviaron personas a los concesionarios para probar coches de segunda mano. Y en un porcentaje alto (hasta el 88%) encontraron datos personales de propietarios y usuarios anteriores.

While they were in the vehicles, they checked the infotainment systems to see whether there was any remnant personal information from previous owners. Eighty-eight percent of the shoppers found personal data left on the vehicles, such as home addresses or phone numbers.

¡Cuidado! ¿Sabrás borrar tus datos personales de tu vehículo cuando lo cambies? ¿Tiene algún mecanismo para evitar que alguien pueda ver, por ejemplo, tu agenda de contactos?

Las APIs también deben tener en consideración la seguridad

Ganchos La proliferación del JavaScript en los clientes, pero también las aplicaciones móviles y, como no, la necesidad de separar la acción de la presentación ha hecho que prolifere el uso de APIs (interfaces de programación de aplicaciones) y es una cosa buena, ya lo decía Bill Joy the Sun Microsytems: ‘la gente más brillante no trabaja para ti’.

no matter who you are, most of the smartest people work for someone else

Así que si, además de tener APIs, las ponemos a disposición de otros es posible que les ayudemos y que nos ayuden. Pero claro, cualquier decisión que tomamos tiene consecuencias desde el punto de vista de la seguridad y de eso hablaba API Security Best Practices que nos recomienda cosas muy básicas, como utilizar https, autentificación, mecanimos de autorización y otras similares. Está bien recordar que en este contexto (a veces más restringido, porque hace falta autorización, o no es tan conocido como la web, o …) hace falta tener las mismas precauciones de seguridad que en cualquier otro proyecto.