Sobre aprender a programar y la frase 'independiente del lenguaje'

Sobre programación En We Should Stop Saying ‘Language Independent.’ We Don’t Know How To Do That una nota interesante sobre la famosa frase ‘independiente del lenguaje’ y cómo el lenguaje en el que aprendemos nos influye.

Habla de la investigación de Allison Elliott Tew y Miranda Parker sobre estudiantes de programación con diferentes lenguajes y cómo los errores que se comenten en unos se parecen más a algunos otros que a la generalidad:

Notice that the most common wrong answer is exactly the same. The 2nd most common wrong answer in Java is idiosyncratic (which is interesting), but the 2nd most common wrong answer for both MATLAB and Python is the 3rd most common wrong answer for Java. The 4th most common wrong answer for Java is the same as the 5th most common wrong answer for Python. We didn’t see that wrong answer in MATLAB, but surprisingly, there were only 4 wrong answers for MATLAB.

Lo que dice el autor es que tenemos lenguajes diferentes porque creemos que eso tiene algún valor (marca alguna diferencia).

We have different languages because we think that those differences make a difference. For an assessment to be language independent, it would have to be measuring something deeper than those differences.

Interesante.

Almacenamiento de información sobre nuestra navegación: cookies y LocalStorage

Galletas Un artículo técnico pero no demasiado sobre cómo almacenan información los navegadores: Cookies vs. LocalStorage: What’s the difference?.

Todos hemos oido hablar de las ‘cookies’ (de manera irremediable por la absurda regulación sobre los avisos y esas cosas que tanto dolor causan en nuestra navegación diaria). No es tan habitual haber escuchado hablar de ‘LocalStorage’, otro sistema de almacenamiento de información (siempre local, otra cosa es lo que se haga con esa información después, claro).

Sobre las cookies, lo de siempre: un poco de información que se utiliza principalmente para hacer seguimiento de nuestra navegación mediante algún tipo de identificador que se nos asigna.

So, what are cookies? According to whatarecookies.com, they are small text files that are placed on a user’s computer by a website.

Que las hay persistentes y de sesión, las primeras tienen fecha de caducidad y las segundas expiran en cuanto cerramos la ventana del navegador (o la pestaña, o lo que sea). Las persistentes quedan almacenadas en nuestro sistema y son las que permiten que no tengamos que identificarnos una y otra vez en los sitios que usamos habitualmente.

Sobre LocalStorage, se trata de un mecanismo introducido con HTML5, que tiene la ventaja de que no es necesario que viaje de un sitio para otro en nuestra navegación en cada enlace que pinchamos (está orientado a almacenar información localmente).

This is because data is stored on the user’s local disk and is not destroyed or cleared by the loss of an internet connection.

Para repasar.

Seguridad en entornos corporativos con sistemas tradicionales

Ordenador grandote No es habitual que tengamos acceso a un ‘mainframe’, uno de esos sistemas grandes capaces de procesar muchísimas transacciones, que en muchos casos han sido sustituidos por infraestructuras más ligeras y a las que sí que tenemos acceso con más facilidad.

En Top Five Security Focus Areas for Mainframes hablaban de estos equipos y resumen los problemas fundamentales de seguridad en cinco.

  • Políticas de contraseñas.
  • Datos olvidados
  • Usuarios con demasiados privilegios
  • Protocolos no cifrados
  • Aplicaciones inseguras

Nada que no podamos esperar encontrar en un sistema basado en otro tipo de comopnentes, pero en estos sistemas parece que no es raro encontrar los problemas por su dificultad de gestión, el tipo de operaciones que se realizan con ellos y laforma en que tradicionalmente se han considerado dentro de las empresas.

Esto es, habitualmente estaban aislados y protegidos físicamente.

First, mainframes were historically physically isolated in what was considered a “secured” space with layers of security controls, so companies assumed they would not be tampered with.

Típicamente están dedicados a tareas de producción y es un problema hacer otras cosas con ellos.

Second, mainframes are typically excluded from security testing because they almost always run production operations.

No hay demasiados expertos en la seguridad en este contexto.

Finally, there is limited mainframe testing expertise

Las herramientas sencillas también nos pueden ayudar a encontrar problemas de seguridad

Un fallo cualquiera Cuando yo empecé a interesarme por el desarrollo seguro de aplicaciones las únicas herramientas que había eran buscadores de cadenas más o menos potentes; estas herramientas no podían ‘comprender’ el flujo del código ni hacer seguimiento de las variables (lo más parecido a eso era el Taint mode de Perl. Posteriormente las herramientas han ido mejorando (y encareciéndose) y ahora son capaces de cosas mucho más interesantes.

Sin embargo, la búsqueda de patrones sigue siendo una herramienta más y de eso habla Don’t Underestimate Grep Based Code Scanning que empieza hablando de las herramientas y cómo el mercado está copado por unos pocos fabricantes de herramientas bastante caras:

The SAST market is dominated by a small number of big players that charge high licencing fees for tools that do sophisticated analysis. One of the main features of such tools is the data flow analysis, which traces vulnerabilities from source to sink, potentially going across a number of files.

Sigue habiendo herramientas más sencillas (y económicas) que también son más eficientes:

There are lower cost, more efficient SAST tools, but they typically do lack the sophistication in terms of quality of security bug findings. Perhaps the most popular low-cost alternative is SonarQube,…

A pesar de todo, como decíamos, se puede usar la búsqueda de patrones (la herramienta prototípica sería grep):

In this blog, we’re going to talk about grep-based code scanning, which is an old fashioned way of SAST scanning — but we argue that good grep based scanning can do reasonably well compared to expensive SAST tools in terms of quality of bugs found.

Y después hace unas cuantas consideraciones para pasar a indicarnos qué buscar, con cadenas como: “password, passwd, credential, passphrase”, o “sql, query(“. Sin olvidar las funciones inseguras como “strcat, strcpy, strncat, strncpy, sprintf, gets” y otras muchas cadenas que pueden darnos indicios de que algo puede que no vaya bien del todo. O, al menos, que tal vez deberíamos mirar allí.

Curioso.

En informática los nombres largos son una mala idea

Sobre nombres Un asunto importante en la informática es el nombre de las cosas. En Long Names Are Long me gustó leer los consejos que dan y por eso lo traigo aquí.

Habla del sistema de revisión de código en Google y también de la importancia que le dan a la legibilidad, para centrarse en la longitud de los nombres (identificadores):

What I want to talk about is something I see in a lot of code that drives me up the wall: identifiers that are too damn long.

Las metas para elegir un buen nombre deberían se la claridad (saber a qué se refiere el nombre) y la precisión (saber a qué no se refiere). Y los consejos:

Omitir nombres obvios para una variable o tipo de parámetro (por ejemplo, incluir el tipo de la variable en el nombre sería desaconsejable).

  1. Omit words that are obvious given a variable’s or parameter’s type

Evitar palabras que no ayudan a eliminar ambigüedades (por ejempo, calificativos redundantes).

  1. Omit words that don’t disambiguate the name

Evitar palabras que se conocen del contexto (por ejemplo, en un método que calcula un valor anualizado, ¿tiene sentido hacer referencia a la anualización en la variable correspondiente?).

  1. Omit words that are known from the surrounding context

Evitar palabras que no significan mucho (o nada). Ejemplos: datos, estado, valor, …

  1. Omit words that don’t mean much of anything

Interesante.

Como bola extra, un viejo artículo sobre el nombrado y como (según Joel Spolski) se pervirtió la idea de la notación húngara (que se nombra en el otro artículo) hasta convertirla en algo absurdo Making Wrong Code Look Wrong.

Identificación de características basada en el tiempo

Reloj Una clase de fallos especialmente sugerente y a los que no siempre se presta atención son los relacionados con el tiempo: un ejemplo serían las condiciones de carrera (cuando algo cambia entre el momento de verificar que una operación está permitida y el momento en que la operación se realiza); el que traemos hoy aquí tiene que ver con el tiempo que se tarda en realizar alguna operación dependiendo de las circunstancias que rodean a nuestro sistema. Un ejemplo clásico de este tipo de errores era cuando buscamos algo: típicamente es más rápido cuando lo encontramos que cuando no está (y eso da pistas sobre valores de algunos datos).

En esta ocasión traemos Detecting incognito mode in Chrome 76 with a timing attack que habla justamente de un problema de este tipo. En Chrome 76 era posible determinar si el usuario utilizaba el modo incógnito por la velocidad de escritura, al utilizar APIs diferentes.

Había un precedente, basado en la cantidad de espacio disponible para poder utilizarse (en Bypassing anti-incognito detection in Google Chrome)

Recently, security researcher Vikas Mishra discovered that we can infer incognito state based on the amount of space which the API makes available.

Y el autor habla de la medición de escrituras, en este nuevo tipo de fallo, que se basa en medir el tiempo que cuesta escribir repetidamente cadenas de caracteres largas:

In this blog post, I present a proof-of-concept of a technique which websites could use to detect incognito users by measuring the speed of writes to the API.

The setup is relatively simple: benchmark the filesystem by repeatedly writing large strings to it and measuring how long that takes. Because memory is faster than disk, we should be able to tell by the speed whether the site visitor is in incognito.

Interesante.

Gestión de sistemas grandes distribuidos

Complejidad (moderada) Una lectura interesante en Operating a Large, Distributed System in a Reliable Way: Practices I Learned sobre la experiencia del autor, Gergely Orosz, en sistemas distribuidos.

Habla de temas como la monitorización, detección de anomalías, gestión de incidentes y muchos otros aspectos que alguien con poca experiencia en este tipo de sistemas podría pasar por alto (o aprender por la vída difícil).

Lo hace desde la experiencia de trabajar con el sistema de pagos de Uber y nos recuerda que cuanto más grande es el sistema, más probable es que se cumpla la máxima aquella de que ‘si algo puede ir mal, irá mal’.

The larger a system, the more Murphy’s law of “what can go wrong, will go wrong” applies. This is especially true with frequent deploys, lots of developers deploying code, multiple data centers involved, and the system being used globally by a large number of users.

Muy interesante.

Las claves (ya) no importan

Puerta fortificada Seguimos dando consejos acerca de las contraseñas (longitud, complejidad, …) aunque lo cierto es que cada vez los sistemas confían menos en ellas y utilizan otro tipo de medidas (segundo factor, principalmente, por elección del usuario o porque el proveedor nos lo suministra cuando tiene dudas).

Por eso me gusta leer todo lo que puedo sobre contraseñas, sistemas de identificación, autentificación y me gustó leer Your Pa$$word doesn’t matter donde se habla de este tema.

Dice que la contraseña no importa:

Because here’s the thing: When it comes to composition and length, your password (mostly) doesn’t matter.

Los atacantes, típicamente, quieren conseguir claves para tener acceso a alguna cuenta (sin un objetivo concreto). Los métodos más sofisticados sólo se usan para objetivos concretos que merecen el esfuerzo.

To understand why, let’s look at what the major attacks on passwords are and how the password itself factors into the equation for an attacker. Remember that all your attacker cares about is stealing passwords so they, or others, can access accounts. That’s a key difference between hypothetical and practical security – your attacker will only do really wacky, creative stuff you hear about at conferences (or wherever) when there’s no easier way and the target of the attack justifies the extra effort.

Asi, conseguir credenciales es relativamente sencillo porque se pueden comprar de ataques anteriores, o mediante phishing, instalando un ‘malware’ y espiando nuestro teclado, y otras medidas similares para las que no importa cómo de compleja sea la contraseña.

Una contraseña ‘diferente’ ayuda cuando el atacante está ‘probando’ diferentes claves y para evitarlo basta con tener una que no sea muy común.

But again, the average attacker is moving so slowly in response to detection systems that they only get a few guesses in. So, your password only matters if it’s included in that short list the attacker is trying. As an admin, you want to prevent use of these commonly attacked passwords when passwords are created or changed.

Si el atacante consigue acceder a la base de datos de claves, es cuestión de tiempo que lo consiga salvo que nuestra clave sea verdaderamente buena.

The point is – your password, in the case of breach, just doesn’t matter – unless it’s longer than 12 characters and has never been used before – which means it was generated by a password manager. That works for some, but is prohibitive for others. If you are using a password manager, use the maximum possible length – there’s no usability downside if you are already cutting and pasting.

Interesante.

Anonimización de datos personales y ataques

Oculto Recientemente se ha hablado en España del tema de anonimización de datos de ciudadanos (lo contaba en Demoscopía tecnológica: Un gobierno que tome decisiones basadas en datos) porque creo que es un buen camino para conocer mejor a los ciudadanos y proporcionarles un buen servicio.

No obstante, soy consciente de que cuando se habla de anonimización, hay que manejar los términos con cuidado. Y por eso me gustó leer Hashing names does not protect privacy; esto es, utilizar un hash de los nombres (o de los identificadores) no tiene por qué supone una anonimización efectiva, sobre todo si el atacante sabe que la entrada proviene de un conjunto de datos restringido (¿números de teléfono? ¿matrículas?).

But you know the input comes from a restricted set, a set small enough to search by brute force, then hash functions are reversible. If I know that you’ve either hashed “yes” or “no,” then I can apply the hash function to both and see which one it was.

Sobre datos personales, siempre estaremos trabajando con un conjunto de datos pequeños donde un ataque de fuerza bruta tiene sentido (sobre todo si se buscan los datos de alguien en particular).

Suppose someone has attempted to anonymize a data set by hashing personally identifying information (PII) such as name, phone number, etc. These inputs come from a small enough space that a brute force search is easy.

Los números son más costosos

Hashing numbers is simpler but more computationally intense. I had to do a little research to find a list of names, but I know that social security numbers are simply 9-digit numbers. There are only a billion possible nine-digit numbers, so it’s feasible to hash them all to make a look-up table.

Para mejorar la situación la propuesta tampoco es muy complicada: en lugar de utilizar el dato, generar una clave que podemos combinar con los valores reales antse de hacer el hash.

One way to improve the situation would be to use a key, a random string of bits that you combine with values before hashing. An attacker not knowing your secret key value could not do something as simple as what was described above.

En temas de seguridad y privacidad siempre hay que ir un poco más allá.

Mejorar la seguridad eligiendo mejores lenguajes

Ardilla Microsoft lleva años mejorando las herramientas y procedimientos para desarrollar código más seguro. En esa línea podemos leer A proactive approach to more secure code donde se habla del problema que suponen los fallos de corrupción de memoria y cómo tratar de evitarlos eligiendo (cuando sea posible) mejores lenguajes desde este punto de vista:

as Matt Miller discussed in his 2019 presentation at BlueHat IL, the majority of vulnerabilities fixed and with a CVE assigned are caused by developers inadvertently inserting memory corruption bugs into their C and C++ code. As Microsoft increases its code base and uses more Open Source Software in its code, this problem isn’t getting better, it’s getting worse.

Tenemos herramientas, pero los desarrolladores no tienen tiempo para usarlas y también existen cada vez más lenguajes que son seguros desde el punto de vista de gestión de la memoria

If only the developers could have all the memory security guarantees of languages like .NET C# combined with all the efficiencies of C++. Maybe we can: One of the most promising newer systems programming languages that satisfy those requirements is the Rust programming language originally invented by Mozilla.

Y también tenemos modelos, como la industria del automóvil y todo lo que ha mejorado la seguridad de los viajeros en la evolución de sus procesos.

We can learn from the way the automotive industry continually evolves their technology to protect drivers and road users. The software security industry has a prerogative to protect the developer in a similar manner. Perhaps it’s time to scrap unsafe legacy languages and move on to a modern safer system programming language?

Habrá que conocer mejor Rust.