Lo leí en algún libro (creo que en el de John Viega y Gary McGraw, ‘Building Secure Software’). Allí se decía que no sólo no se enseñaba el tema del desarrollo seguro sino que, además, los ejemplos que se podían ver en los libros de programación (en aquella época libros, fundamentalmente) eran de dudosa calidad desde el punto de vista de la seguridad. También se discutía (creo) sobre los ejemplos y sobre los ficheros de configuración. Desde entonces es un tema que suelo comentar (lo hice, por ejemplo, en la charla del otro día Una charla sobre seguridad en aplicaciones web: principios y más. Casi 20 años después seguimos igual: en Top-ranked programming Web tutorials introduce vulnerabilities into software nos dicen algo muy similar. Los tutoriales más importantes de desarrollo web incluyen ejemplos y soluciones vulnerables.

La forma de obtener el dato es curiosa: navegan por el repositorio GitHub y encuentran vulnerabilidades que pueden encontrarse en algunos textos introductorios disponibles por ahí.

Researchers from several German universities have checked the PHP codebases of over 64,000 projects on GitHub, and found 117 vulnerabilities that they believe have been introduced through the use of code from popular but insufficiently reviewed tutorials.

Utilizan la búsqueda en el repositorio de patrones bien conocidos de fallo, que se pueden encontrar en los tutoriales. Y encuentran problemas, claro:

Thanks to our framework, we have uncovered over 100 vulnerabilities in web application code that bear a strong resemblance to vulnerable code patterns found in popular tutorials. More alarmingly, we have confirmed that 8 instances of a SQLi vulnerability present in different web applications are an outcome of code copied from a single vulnerable tutorial,” they noted. “Our results indicate that there is a substantial, if not causal, link between insecure tutorials and web application > vulnerabilities.”

Casi nada. En un caso concreto 8 ejemplos de un fallo que proviene de uno de estos tutoriales.

Proporcionan sus herramientas GithubSpider para hacer las búsquedas, y ccdetection para hacer la detección de código similar.

Si haces cursos y tutoriales, o si ya tienes algunos publicados, tienes una responsabilidad.

También tengo que decir que hace años propuse algo así (cuando pensábamos en temas de propagación de información) relacionado con la propagación de errores en los programas a través de ejemplos, copia, etc. en una presentación que nunca llegué a publicar, así que pueden creerme o no sobre el tema.

El otro día mi amigo Gabriel del Molino (@gmolino) me invitó a dar una charla a sus alumnos de un curso de formación para desempleados donde reciben una panorámica de desarrollo web. La propuesta era abierta pero estaban especialmente interesados en temas de seguridad.

Como se trataba de una sesión única y no era plan de entrar en detalles técnicospreferí presentar algunos principios y completarlo con una introducción motivadora, algunas ideas sobre identificación y autentificación y, finalmente, recordar que nuestro trabajo casi siempre tiene que ver con la economía y con las personas.

Dejo aquí la presentación por si a alguien puede servirle de algo.

Se habla con mucha frecuencia de la autentificación, y de los diversos sistemas disponibles, pero no hay que olvidar que si queremos estar seguros no podemos confiar sólo en ellos. Cada vez más tenemos que utilizar la información adicional de la que dispongamos para estar seguros de que el usuario es quién dice ser.o

En Trust, but Verify: Authentication Without Validation Is Naïve daban algunas ideas sobre ello.

Primero, alguna paradoja: es más probable que las preguntas de seguridad las responda adecuadamente un atacante que el legítimo propietario de la cuenta:

Gartner research, however, found that users fail to answer their knowledge-based questions 15–30 percent of the time, while fraudsters answer correctly 60 percent of the time. Malicious actors often find this information on social networks or through phishing schemes.

Si confiamos en dispositivos como los teléfonos para la validación también nos podemos encontrar problemas:

his practice has shifted to mobile phones, with OTPs being sent as text messages. However, mobile malware can intercept these messages and forward them to fraudsters.

Y, desde luego, la biometría también tiene sus problemas:

… which has led to the exponential growth of fingerprint reader-enabled devices. It didn’t take long, however, for cybercriminals to circumvent this technology

¿Entonces? Como decíamos, hay que ser capaces de utilizar la información extra de la que dispongamos. Por ejemplo, sobre el comportamiento, y otros identificadores.

Parece que el tema de la generación informática de números aleatorios ha ganado interés en los últimos años. Hoy lo decimos por el contenido de A Brief History of Random Numbers donde se habla del tema desde una perspectiva histórica: la aleatoriedad es algo muy abundante en la naturaleza, pero no es sencilla de obtener con herramientas humanas:

The randomness so beautifully and abundantly generated by nature has not always been easy for us humans to extract and quantify.

Los primeros intentos informáticos parecen datar de los años 40, de la mano de RAND Corporation:

… the modern world demanded a lot more random numbers than dice or yarrow stalks could offer. RAND Corporation created a machine that would generate numbers using a random pulse generator.

Posteriormente hubo algunos intentos más, hasta que surgió la idea de los generadores de números seudoaleatorios (pseudorandom number generator, PRNG). Se comentan algunas de las aproximaciones algorimicas y también curiosidades como LavaRand, diseñado por Silicon Graphics, y basado en un par de lámaras de lava y una cámara tomando imágenes. Por cierto, el método sigue vigente, según nos contaban en 10% of the Internet Is Encrypted with Lava Lamps, hablando del proveedor Cloudflare.

También se comenta sobre iniciativas como los servicios proveedores de números aleatorios, como Random.org y cómo, finalmente, Intel añadió en 1999 un generador en su chipset i810 para servidores, basado en el ruido térmico de los procesadores:

In 1999, Intel added an on-chip random number generator to its i810 server chipset. Finally, new servers had a good local source of randomness from thermal noise — a true random number generator (TRNG).

Sin embargo, no hay que olvidar que no sólo necesitamos números aleatorios, sino que los necesitamos a velocidad adecuada; y no sólo necesitamos números seudoaleatorios, sino que necesitamos números seudoaleatorios seguros (Aleatoriedad y juego en línea. No sólo para juegos, claro).

Finalmente, se habla (habiendo pasaro por otros temas) de las discusiones sobre qué esquemas de generación utilizar, cuando hablamos de programas con la seguridad en mente, o simplemente de otros usos menos comprometidos.

Personalmente, hace algún tiempo que dejé de dar consejos sobre la creación de contraseñas. Creo que la solución para cualquier usuario es utilizar un gestor de contraseñas y eso es lo que recomiendo cuando alguien me pregunta. O cuando med dejan decirlo sin que me pregunten. También digo, si alguien se empeña en crearlas y recordarlas que lo mejor es que sean largas (desde luego, más de 10 o 12 caracteres, en este momento).

Las normas de creación de contraseñas pueden tener sentido si se hacen bien, pero es bastante fácil que hagamos recomendaciones malas (he visto algunas horribles y otras que, en lugar de ayudarnos a mejorar nos perjudican) y que, aunque sean buenas, se sigan mal.

De ello hablaba Jeff Atwood en Password Rules Are Bullshit

Desde el otro lado, los consejos que da son:

• Las reglas son una basura
• Fuerza una longitud mínima (en Unicode)
• Verifica que no se utilizan contraseñas comunes
• Verifica que tienen una mínima diversidad (entropía)
• Verifica casos especiales (usuario, correo, … No deberían ser contraseñas)

Interesante.