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.

Otro tutorial, esta vez sobre las ‘cookies’ en A practical, Complete Tutorial on HTTP cookies. Con ejemplos en Flask que es una tecnología cercana al Python que conozco poc y que, tal vez, debería explorar.

Incluye:

• Trabajar con cookies en el frontal y en el servidor.
• Seguridad y permisos de las cookies.
• Interacción entre cookies, AJAX y CORS.

Cuando maneja estas cosas en su día a día está bien refrescar y conocer lo que va habiendo (y cambiando). Cuando no, leer estos artículos es como una ‘gimnasia’ `para no despistarse si alguna vez lo llegamos a necesitar.

De vez en cuando alguien nos pone al día de los nuevos (y viejos) temas de seguridad web que tenemos que tener en cuenta. Son entradas que no hay que tomar como palabra de ley, porque siempre puede olvidarse algo o darle más importancia de la necesaria, pero nos sirven de recordatorio y para repasar.

En este caso hablamos de Web security knowledge you must understand it (Part I: HTTPS, TLS, SSL, CORS, CSP).

Interesante.

Ya hemos hablado otras veces de criptografía: que no hay que inventarla, que hay que usar métodos conocidos y reconocidos… Sin embargo, no es tan fácil ponerse a utilizar criptografía, sobre todo cuando lo que alguien quiere es tan sencillo como cifrar sus datos de manera razonable, sin tener que convertirse en un critptógrafo o un criptoanalista. Por eso me gustó leer Cryptography for programmers 2: Blocks and Randomness donde explican justamnente esa parte, los bloques y cómo se emplean en el cifrado y el tema de la aleatoriedad (otro ‘favorito’ de este sitio).

Si alguien está interesado la entrada forma parte de una serie de cuatro, dedicadas a los principios básicos, y otros temas interesantes, además de este.

Se habla de cifrado simétrico y asimétrico para luego hablar de la criptografía de bloques, que es la que suele utilizarse cuando se habla de cifrado simétrico.

Block cryptography is the default symmetric cryptography used nowadays, and so it will be the only symmetric cryptography that will be covered in the series.

La idea es cifrar una cantidad fija de bits mediante un algoritmo simétrico y los bloques nos permiten manejar estas cuestiones. Luego pasa a explicarnos qué tipo de bloques serían recomendables.

For the purpose of this post I would say as a programmer there is no reason you should be using anything other than AES. AES is the current standard, it is secure enough and will very likely continue to be for a long time, specially if you are using the variant with a 256 bit key, which I would recommend.

Luego habla de los generadores de números seudoaleatorios, que es un tema que hemos tocado más veces aquí.

Interesante.

Hay toda una familia de ataques que se basan en tratar de obtener información sobre un sistema a partir de lo que llaman canales laterales: variaciones de diferentes parámetros que pueden medirse y que pueden ayudar a un atacante a obtener información.

Hoy traemos Exfiltrating Data from Air-Gapped Computers via Wi-Fi Signals (Without Wi-Fi Hardware) que habla de cómo se puede comprometer un sistema para que los chips de memoria de nuestro ordenador pudieran llegar a generar emisiones electromagnéticas en la banda de 2.4GHz como si fuera una WiFi. Estas señales podrían ser recibidas por múltiples dispositivos que estuvieran en las proximidades y se podrían utilizar para robar información.

Dubbed “AIR-FI,” the attack hinges on deploying a specially designed malware in a compromised system that exploits “DDR SDRAM buses to generate electromagnetic emissions in the 2.4 GHz Wi-Fi bands” and transmitting information atop these frequencies that can then be intercepted and decoded by nearby Wi-Fi capable devices such as smartphones, laptops, and IoT devices before sending the data to remote servers controlled by an attacker.

Al ser generado por los chips de memoria, no es necesario que el sistema tenga antenas WiFi ni nada parecido; el atacante simplemente puede generar esas emisiones electromagnéticas y enviar datos a través de ellas.

“Instead, an attacker can exploit the DDR SDRAM buses to generate electromagnetic emissions in the 2.4 GHz Wi-Fi bands and encode binary data on top of it.”

Esta sería una posible vía de ataque para robar información de sistemas desconectados de la red, claro.

Para poder realizar el ataque es necesario infectar el equipo, y disponer de otro que haga de receptor y que esté suficientemente cerca.

Curioso.