Ya hace muchos años que descubrimos las APIs abiertas (por ejemplo, en Flickr) y las posibilidades que ofrecían. Sin embargo (igual es mi impresión) en los últimos años se está hablando más, y hay quién lo hace mejor y quién lo hace peor. Recordemos aquí que un API es un mecanismo para desarrollar programas con los servicios de alguien: nos proporciona una forma de llamar a sus ‘primitivas’ básicas y, en consecuencia, hacer programas para nuestro uso (y el de otros) con las herramientas de su plataforma.

Slack es uno de esos casos donde permiten la creación de bots y diversos autoamtismos sobre su plataforma y en How We Design Our APIs at Slack hablan del diseño de sus APIs.

La motivación tiene con que sean cómodas de usar, los desarrolladores tengan ganas de hacerlo y generen proyectos interesantes.

If APIs are designed well, developers will love them, and can become the most creative innovators using your APIs. They will invest heavily, and sometimes even become evangelists for your APIs. We also value a developer’s time and the resource they risk by building on our platform. Bad API design leads to a bare minimum adoption, and even frustration. Bad APIs become a liability for a company.

Y luego nos dan sus principios:

Hacer una cosa y hacerla bien.

1. Do one thing and do it well

Hacer fácil y rápido el comienzo.

1. Make it fast and easy to get started

Preouparse de la consistencia intuitiva.

1. Strive for intuitive consistency

Devolver errores con significado.

1. Return meaningful errors

Diseñar para el crecimiento y las prestaciones.

1. Design for scale and performance

Evitar cambios disruptivos (que rompan cosas)

1. Avoid breaking changes

Luego hablan del proceso de diseño, en cuatro pasos: escribir una especificación, revisarla internamente, recibir realimentación de los primeros colaboradores y tener una fase de pruebas

1. Write an API spec
2. Internal API review
3. Early partner feedback
4. Beta testing

Interesante.

Ya hemos hablado más veces de los canales laterales para robar información. En Crean señales inalámbricas con un cable Ethernet para robar datos nos contaban la posibilidad de utilizar los omnipresentes cables para:

generar emisiones electromagnéticas en las bandas de frecuencia de 125 MHz que luego son moduladas e interceptadas por un receptor de radio cercano.

Se han hecho pruebas de concepto:

los datos transmitidos desde una computadora con espacio de aire a través de su cable Ethernet se recibieron a una distancia de 2 metros.

Claro, esto requiere infectar la máquina en cuestión y luego poder sacar provecho del mecanismo pero, desde luego, teóricamente es posible.

Hay una broma recurrente por ahí que habla de que los programadores ya no tienen que saber casi nada. Todas las soluciones están, nos dicen, en StackOverFlow y otros foros similares.

Sin embargo, y no es la primera vez que hablamos de ello, lo cierto es que muchsas veces es mala idea copiar código incluso de los libros, sobre todo si nos preocupa la seguridad.

En If you copied any of these popular StackOverflow encryption code snippets, then you coded it wrong hablan del tema.

El autor revisa código y encuentra fragmentos de código que están mal y que ha encontrado en ese foro:

Security code reviews is a task that I do on a daily basis, and have been doing for the last thirteen and a half years. In this time, I have reviewed several hundred code bases, and have come across cryptographic code many times. More often than not, there have been security issues in cryptography code that I have reviewed. Very often I have traced these bogus code snippets to StackOverflow answers that got highly upvoted.

La entrada se dedica a mostrar varios ejemplos, con contraseñas en el código al utilizar criptografía, por ejemplo. También semillas y otros fallos de más alto nivel. A veces, incluso como soluciones con mayor número de votos positivos. Que contienen errores.

The current highest voted issue has 187 upvotes at the time of writing. This answer gives a nice overall education about how to do encryption properly, and it is definitely worth a read. The only niggle I have is the SecureRandom( ) confusion …

Muy interesante. Y un recordatorio de que no hay que fiarse de soluciones más o menos cómodas que encontremos por ahí.

Vivimos (llevamos viviendo ya bastante así) tiempos confusos. Por un lado, parece que la seguridad informática tenga que ver sólo con saber encontrar vulnerabilidades y nos recordaba Bernardo Quintero esta mañana que no:

Recordatorio ahora que estamos en plena burbuja formativa: ciberseguridad no es saber usar metasploit, ni la mayoría de vacantes en la industria van a estar relacionadas con habilidades ofensivas. Ya, ya se que mola eso de hacer de "hacker", pero los buenos hackers construyen.

— Bernardo Quintero (@bquintero) February 14, 2022

No hay que olvidar que nuestro trabajo será más bien el de proteger nuestros propios sistemas y programas que el de andar descubriendo fallos por ahí.

Por otro lado, hay una gran confusión entre lo que son errores, fallos, vulnerabilidades (y luego si lo son de codificación, de la arquitectura, …). Todo puede causar problemas, pero de muy diferente nivel. Yo antes quería pensar que era porque todavía no había madurado suficientemente el conocimiento para hacerlo mejor, pero el tiempo pasa y no cambia casi nada.

El proyecto OWASP Top 10 es un documento de la OWASP que incluye una lista de problemas de seguridad según lo que se está viendo en cada momento como mayores problemas de seguridad. En este sentido se lanza un proceso de recogida de información de empresas, expertos, … para recopilar los problemas más frecuentemente observados. En este sentido, es un indicador valioso porque nos puede ayudar a mirar en aspectos que, a lo mejor, estábamos pasando por alto. O reforzar nuestro criterio con respecto a problemas que otras personas no consideran.

De algunas de estas cosas nos hablaba Daniel Miessler en Thoughts on the OWASP Top 10 2021.

¿Qué es la lista del OWASP Top 10? ¿Una lista de vulnerabilidades? ¿Una lista de categorías? ¿A quién va dirigida?

Is it a list of vulnerabilities? Is it a list of vulnerability categories? Is this for developers? Is this for security companies? Is this for security tool output labeling? Is it a tool for helping security metrics functions within companies?

Algunos de los problemas son completamente intangibles, como ‘Diseño inseguro’.

The addition of Insecure Design is one of the problems. While I think everyone can agree it’s important, it’s not a thing in itself. It’s instead a set of behaviors that we use to prevent issues.

La mezcla de categorías y vulnerabilidades es un problema, nos dice.

The mixing of categories and vulnerablities has always been a huge problem for me, both as a user and as an OWASP Project Leader.

Y, claro, en algunos casos los problemas pueden caer en varios apartados.

Then you have the situations where things can fall into multiple categories. Not turning off FTP on your home router can be Security Misconfiguration and also Insecure Defaults.

Y algo parecido sucede con el registro de seguridad y vigilancia: ¿qué es exactamente lo que se espera de nosotros?

Security Logging and Monitoring suffers from something similar to Insecure Design. Namely, it sits in this weird realm between tangible and being part of a security review process.

Sin embargo, aparece un problema específico (SSRF, Server Side Request Forgery), como vulnerabilidad en esta variada lista.

And then we have the lonely SSRF at number 10. The only specific issue on the list. I mean it’s a good vuln, but it stands out like a vulnerability on a category list, which it is.

La lista tiene valor. Y una buena cantidad de trabajo detrás. Pero igual habría que empezar a pensar en lo que se quiere representar en esta lista y cómo ha de utilizarse.

The list still provides value. It does. And I appreciate everyone’s work on the project. I just think it would be far more useful with more clarity around its identity and intended use

La computación distribuida trata de sacar partido de diferentes recursos de cálculo que podemos tener a nuestra disposición. Es un modelo que tiene sus ventajas (aumento de capacidad) y sus inconvenientes (complicaciones). En Navigating the 8 fallacies of distributed computing nos habla de algunos mitos.

Los mitos:

• La red es fiable. Las redes son complejas, dinámicas y a veces impredecibles. Hay demasiadas cosas que pueden fallar.

Networks are complex, dynamic, and often unpredictable. Many reasons could lead to a network failure

• La latencia es cero. Mientras que en una red de área local esto puede ser cierto, en redes más amplias veremos rápidamente que no.

Latency may be close to zero when you’re running apps in your local environment, and it’s often negligible on a local area network. However, latency quickly deteriorates in a wide area network.

• El ancho de banda es infinito. Cuando usamos la red parece que no tenemos limitaciones, sin embargo, si tenemos que manejar volúmenes de datos importantes, encontraremos rápidamente las dificultades.

… the capacity of networks is not infinite (partially because our appetite for generating and consuming data has also increased). When a high volume of data is trying to flow through the network, and there is insufficient bandwidth support, various issues can arise…

• La red es segura. Nuevamente, muchas cosas pueden fallar: fallos, vulnerabilidades, ataques, …

There are many ways a network can be attacked or compromised: bugs, vulnerabilities in operating systems and libraries, unencrypted communication, oversights that lead to data being accessed by unauthorized parties, viruses and malware, cross-site scripting (XSS), and DDoS attacks, …

• La topología no cambia. La forma en que se conectan los equipos y las redes entre sí es algo más o menos permanente, menos cuando no lo es: fallos, accidentes, … pero también reconfiguraciones y rediseños.

In a nutshell, network topology refers to the manner in which the links and nodes of a network are arranged and relate to each other. In a distributed system, network topology changes all the time. Sometimes, it’s for accidental reasons or due to issues, such as a server crashing. Other times it’s deliberate — we add, upgrade, or remove servers.

• Hay un administrador. Si el sistema es muy pequeño, puede ser cierto (y también que no haya ninguno). En cualquier sistema un poco más grande las posibilidades aumentan.

There might be only one administrator in the case of a very small system, or perhaps in the context of a personal project. Beyond that, there is usually more than one administrator of a distributed system in nearly all real-life scenarios.

• El coste de transporte es cero. Vivimos en la ficción de que el coste de enviar información por las redes es cero. Sin embargo, la infraestructura tiene coste, los aparatos también y luego hay que gestionar y mantener esos recursos.

First of all, networking infrastructure has a cost. Servers, network switches, load balancers, proxies, firewalls, operating and maintaining the network, making it secure, not to mention staff to keep it running smoothly — all of these cost money. The bigger the network, the bigger the financial cost.

• La red es homogénea. Esto no es cierto ni en una red doméstica. En muchos casos las redes van creciendo de forma casi orgánica, con sistemas diferentes, protocolos, etc.

Often, not even your home network is homogenous. It’s enough to have just two devices with different configurations (e.g., laptops or mobile devices) and using different transport protocols, and your network is heterogeneous.

Como conclusión, lo que anticipábamos arriba: construir sistemas distribuidos es difícil.

A brief conclusion: building distributed systems is hard