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.

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.

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.

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.

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.