En algunas ocasiones tenemos nuestras APIs en un dominio diferente del que utilizamos para nuestra web. Pero la web necesita acceder al API y eso significa que podríamos tener problemas con el acceso a los recursos.

Para situaciones como esta se define Cross-Origin Resource Sharing (CORS) y en Clarifying CORS - Cross-origin Resource Sharing nos ayudan a comprenderlo mejor.

Interesante.

A veces recomendamos demasiado alegremente que la gente registre un dominio para gestionar su ‘marca’ (personal o de empresa) y nos olvidamos de las consecuencias negativas que esto puede tener si no se tiene un poco de cuidado. Actualización (2022-11-19): casualmente veo este artículo argumentando a favor del uso de un dominio, Why everyone should register a domain name. Es de hace tiempo, pero muestra la idea.

Vale: utilizar una dirección de correo electrónico genérico puede parecer poco profesional, pero todavía es peor si no mantenemos el compromiso con el dominio que elijamos.

En Thousands of npm accounts use email addresses with expired domains nos cuentan el caso de un análisis de los paquetes npm y han descubierto que hay miles de desarrolladores de JavaScript que han utilizado dominios de correo que después han caducado para registrar sus cuentas en npm (Node Package Manager):

An academic research project found that thousands of JavaScript developers are using an email address with an expired domain for their npm accounts, leaving their projects exposed to easy hijacks.

De hecho, algunos de estos dominios estarían a la venta en algunos sitios.

Researchers said they found that 2,818 project maintainers were still using an email address for their accounts that had an expired domain, some of which they found on sale on sites like GoDaddy.

Esto es un problema porque alguien que lo descubra podría intentar hacerse pasar por el desarrollador en cuestión y, tal vez, conseguir algún objetivo peligroso.

The team argued that attackers could buy these domains, re-register the maintainer’s address on their own email servers, and then reset the maintainer’s account password and take over his npm packages.

Algunos paquetes, al instalarse, ejecutan scripts, muchos paquetes tienen un número importante de personas manteniéndolos y algunos lo que tienen son contribuidores. Sin olvidar las dependencias que existen entre unos paquetes y otros.

2.2% (33,249) of packages used install scripts, which could be abused to run malicious commands and is against npm best security practices;

The Top 1% packages (14,941) had an average of 32.4 maintainers per package, opening the door for attacks via the accounts of inactive or inattentive developers;

389 packages had 40 contributors for every maintainer, opening the door for the accidental insertion of security flaws or flooding a project with contributions to sneak in malicious code;

The top 1% maintainers own an average number of 180.3 packages with direct dependents of 4,010 average packages, meaning some developers could be overworked or not have time to thoroughly maintain or review package changes.

Al final, el problema se debe a una identificación débil de las personas: una dirección de correo. Pero mientras las cosas estén así debemos tener cuidado con los dominios y lo que hacemos con ellos, porque nos podemos llevar un disgusto. Con cualquiera de los activos digitales que hayamos registrado usando estos dominios.

Seguimos con la cadena de suministro. Recordatorio: se trata de atacar alguno de los elementos de los que depende nuestro proyecto, pero que están gestionados por otras personas (servicios, bibliotecas, …).

En How Hackers Compromise the Software Supply Chain hablan del tema.

If you consider all the components you need for your software, you have a pretty long chain, and those components have dependencies too. Any weak link can compromise the entire software supply chain, putting your business at risk.

¿Ocupación de nombres? Ya habíamos hablado de los paquetes que se llaman parecido a otros legítimos y que la gente termina instalando sin darse cuenta. Imaginemos ahora que un atacante descubre algún nombre de un proyecto que se aloja en un repositorio privado. ¿Podría registrar ese nombre en uno público y engañarnos?

If hackers find the name of one of the private repositories, they can register public repositories with the same name and upload their version of what is supposed to be an internal library.

En cualquier caso, es muy difícil evitar cualquier problema de este tipo que pueda aparecer. Los consejos: seguir una política muy estricta de proveedores, registrar repositorios públicos con los nombres de los privados, actualizar los programas (con sus propios riesgos), asegurar todos los ficheros de configuración, tener especial cuidado con las cuentas privilegiadas (si les engañan a ellos será peor), tener niveles de defensa y monitorización (vigilancia) y compartimentalizar. Nada muy nuevo, pero a veces lo olvidamos.

Have a stricter vendor policy. Don’t source from multiple private registries when you can use only one.

When you register a private repository, register a public repository with the same name to prevent typosquatting.

Keep all software up to date, even if the update process is now a risk too.

Secure all configuration files and never deploy them on production, or, at least restrict their access.

Be extremely careful with IT management interfaces. Privileged accounts with a super high level of access should be few.

Have several layers of defense and use monitoring tools such as SIEM or SOAR to detect suspicious behaviors early.

Segment your networks. Don’t let any breach at a low level expose the whole system.

El (pen)último fallo de moda ha sido, desde este verano, el ataque a la cadena de suministro.

De ello nos hablan en Secure software supply chain: why every link matters y nos dicen que se refiere a bibliotecas, código, hardware y otras herramientas que nos proporcionan (o directamente tomamos) otros y que nos sirven para nuestros propios proyectos.

In software, the raw materials are common libraries, code, hardware, and tools that transform code into a final deliverable. This deliverable can be deployed as either a user-facing application, a service (starting over with the same supply chain loop), or another package artifact that is included as a dependency, part of a different product.

Si alguien ataca a alguno de estos proveedors, ¿qué sucederá con nuestro proyecto?

Software supply chain attack happens when some malicious element is introduced in this chain.

A successful attack in any link of the supply can propagate the compromised code or component downstream, completely unnoticed, and cause mayhem across different stages.

Álvaro Iradier cuenta varios ejemplos, y algunas recomendaciones. La principal: establecer conexiones fuertes con proveedores confiables y verificados.

So the approach for securing every single piece and link is very different and cannot be covered as a whole. But, whether you are a supplier or a consumer (or both), you need to put the focus on securing your processes and establishing strong connections with trusted and verified providers.

JavaScript no es mi lenguaje favorito y estoy por decir que sus efectos en la web de hoy en día están siendo poco útiles. Sin embargo, simpatizo con cualquier cosa que nos pueda hacer mejorar en algo y en How JavaScript engines achieve great performance porque, seguramente, se pueda aplicar a más dominios.

Me quedo con dos pinceladas, la detección de funciones ‘calientes’ (hot), esto es, funciones que se llaman con frecuencia y su traducción a instrucciones de máquina (otpimización cuando se necesita y no todo el rato: lo que haríamos con un perfilador). Con la ventaja de que al haberla ejecutado ya algunas veces se pueden hacer todavía más optimizaciones, estas especulativas, que todavía podrían hacer el código más rápido.

Whenever the JavaScript engine detects that a function is hot (that is, executed many times) it hands that function over to an optimizing compiler. This compiler translates the virtual machine instructions into actual machine instructions. What’s more, since the function has already been run several times, the optimizing compiler can make several assumptions based on previous runs. In other words, it can perform speculative optimizations to make even faster code.

Si se descubre que las suposiciones son falsas, se puede ‘desoptimizar’ y volver a comenzar el proceso.

What happens if, later on, these speculations turn out to be wrong? The JavaScript engine can simply delete the optimized, but wrong, function, and revert to using the unoptimized version. Once the function has been run several more times, it can attempt to pass it to the optimizing compiler again, this time with even more information that it can use for speculative optimizations.

Hay más, pero lo que procede es recomendar la lectura para sacarle todo el partido. Sobre todo si están interesados en el tema.