Desde que empecé a fijarme en los temas relacionados con el desarrolo seguro me ha llamado mucho la atención el proyecto OWASP: un grupo de voluntarios proporcionando información, documentación, consejos,… y siendo referenciados desde las más diversas fuentes como un proyecto que hay que tener en cuenta.

En esta ocasión se trata de GitHub, y How to mitigate OWASP vulnerabilities while staying in the flow donde tratan de reflejar las caracterísiticas y procesos de seguridad en los que GitHub puede ayudarnos, con referencia al proyecto OWASP.

Se habla, en particular, del OWASP Top 10, con su lista de fallos frecuentes e importantes.

Fortunately, the Open Web Application Security Project (OWASP) can help. OWASP provides a Top 10 list of vulnerabilities that gives developers and organizations the context they need to address security and compliance risks within their applications.

GitHub tiene un libro sobre el tema, Secure code without disrupting innovation que no conocía.

Los fallos que comentan son:

• Fallos relacionados con la criptografía.

Fundamentalmente se concentran en los secretos que pueden ser difundidos a través del sistema de gestión del código.

However, sometimes API keys, clear text passwords, security tokens, and other sensitive data may remain in code, leading to cryptographic vulnerabilities.

• Fallos de inyección.

Como todos saben, fallos de inyección pueden ocurrir en la web, pero también en los caminos (paths) de nuestras llamadas, en las órdenes SQL, …

Cross-site scripting, path injection, SQL injection, and NoSQL injection are several of the vulnerabilities that have plagued applications for years and continue to stay in the OWASP Top 10 list.

• Diseño inseguro.

Se centra, en este caso, en el modelado de amenazas.

Threat modeling strategies can be implemented to encourage collaboration between developers, security professionals, and even risk management teams.

• Componentes vulnerables y desactualizadas.

De nada sirve diseñar nuestro código con seguridad si luego depende de componenetes que no tenemos adecuadamente actualizadas.

One of the best strategies for managing the risk of vulnerable and outdated components is to alert developers as soon as a security threat is found and give them the ability to take action in their normal workflows and tooling.

No me considero muy bueno programando (torpecillo, a veces) pero sí que me considero bastante hábil encontrando fallos. Supongo que tiene que ver con mi propia torpeza, pero también con la experiencia, al trabajar con estudiantes que cometen errores de forma bastante creativa. Al menos en algunas ocasiones.

Por eso me gusta leer sobre estos temas y, en particular, encontré 5 ways to find bugs donde nos aporta algunas estrategias básicas.

• Poner en el buscador el mensaje de error.
• Divide y vencerás (esto es, reducir el tamaño del problema para encontrar mejor el fallo).
• Método científico (recoger información, establecer una hipótesis y demostrarala o falsarla).
• Depuración del patito de goma (explicar el problema a alguien lejano al mismo: esto nos ayuda muchas veces a pensar en cosas que normalmente pasaríamos por alto. Ese alguien podría ser un patito de goma, de ahí el nombre).
• Alejarse del problema. Esto es, lo dejamos estar y nos dedicamos a otra cosa; seguramente, después de un tiempo, cuando volvamos, será más fácil encontrar el problema.

Curiosamente, justo ayer me pasó con un error de hace tiempo (que incluso había olvidado) que resolví en un ratito después de perder algo de tiempo en su día y no conseguirlo.

Hace unos meses dejé una cosa que no me salía por pura desesperación. Ha sido retomarla y resolverlo en minutos. Qué cosas...

— fernand0 (@fernand0) January 22, 2023

Mucho ha cambiado la cosa desde los tiempos en los que era habitual administrar una máquina (o conectarse a ella) utilizando el viejo telnet. Quién más quien menos utiliza su versión favorita de un cliente de ssh (en Windows he visto usar mucho putty). Pero con esta herramienta se pueden hacer algunas cosas más. De eso nos hablar SSH: More than secure shell que nos muestra algunas posibilidades como:

• utilizar el acceso sin la contraseña del sitio remoto, basado en una clave local
• ejecutar programas en el sistema remoto
• copia ficheros
• establecer una configuración para cada sistema remoto
• configurar el servidor de ssh, el sshd
• hacer una redirección de puertos en el sistema local
• hacer una redirección de puertos en el sistema remoto
• establecer un proxy para navegar con Firefox.
• usar el sistema de ficheros remoto desde el sistema local.
• usar ssh en Windows: putty
• usar ssh en iOS: iSSH

Interesante.

Seguimos con recursos formativos/informativos. Hoy sobre el protocolo que subyace debajo de la publicación de las páginas web The HTTP crash course nobody asked for.

No es una lectura entretenida, pero seguro que sirve de recurso para tener a mano cuando nos preguntemos por algunos detalles de las herramientas que utilizamos en nuestro día a día.

No es la primera vez (ni será la última) que traemos un listado de recomendaciones sobre cabeceras de seguridad en el protocolo HTTP. Hoy dos, en lugar de una:

• Security headers quick reference
• OWASP Secure Headers Project

El segundo es un proyecto de OWAS, que si se va manteniendo puede ser una fuente de consulta para el futuro.