Java sigue siendo un lenguaje de amplio uso y por eso es bueno conocer los problemas de seguridad que podemos tener utilizándolo. En este caso XML Security in Java y los problemas que nos cuentan son casi todos viejos conocidos (expansión de entidades, inyecciones, y otras ‘diabluras’). Interesante, aunque no trabajes con Java, si necesitamos procesar XML de vez en cuando.

No suelo traer aquí con tanta frecuencia otros temas relacionados con mi trabajo (en particular, con mis clases) pero me gusta anotar algunas cosas y en esta ocasión le ha tocado a Finally, a Fast Algorithm for Shortest Paths on Negative Graphs por varios motivos.

El problema de encontrar los caminos mínimos (de menor peso) en un grafo está resuelto hace mucho tiempo (año 1956 por Edsger Dijsktra) con una estrategia vorazsiempre que los pesos sean positivos. Sin embargo, la cosa se complica cuando permitimos que haya pesos negativos en el grafo. Tanto, que sigue siendo un problema a la espera de buenas soluciones.

La existencia de estas soluciones eficientes pueden hacernos pensar que ya no es interesante preocuparse de estos problemas. Sin embargo, de vez en cuando recibimos ‘buenas’ noticias, como en este caso: se ha publicado una solución Negative-Weight Single-Source Shortest Paths in Near-linear Time para el problema más general, que permite ejes de peso negativo.

Aunque dicen que es un algoritmo sencillo de explicar y de programar, conviene rdecir que hay que descomponer el grafo y utilizar técnicas de aleatorización.

Seguimos con GitHub. En esta ocasión 5 tips for embedding security into your workflows. Como dice el título, cinco recomendaciones para integrar la seguridad en nuestro flujo de trabajo.

• Herramientas de seguridad cercanas al código.

Aquí tratan de ‘vendernos’ sus integraciones, claro.

• Reemplazar una aproximación reactiva por una proactiva.

Que los problemas no nos sorprendan porque ni siquiera habíamos pensado en ellos.

• Mantener una buena relación señal/ruido.

El problema de muchas herramientas de seguridad es que son muy ruidosas: se hace complicado discriminar el grano de la paja y terminan siendo una fuente de molestias en lugar de una ayuda.

While security tools are needed, they often cause more headache than help. This is because the aforementioned third-party security apps most organizations use are slow, create noise, and may not be integrated into the native developer environment.

• Permitir la realimentación sobre aspectos de seguridad cuando colaboramos con otros.

Cuando otros colaboran con nosotros (o nosotros con ellos) es bueno poder vigilar lo que va sucendiendo en el código.

• Automatizar los procesos de seguridad.

Cuando sea posible, hacer pruebas y comprobaciones de seguridad de manera automática.

Como decía arriba, se trata de publicitar su servicio GitHub Advanced Security pero los consejos son relevantes y podemos usar sus herramientas u otras.

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