¿Cuál fue tu primera came?

Para escribir esta entrada he invertido 1h 52m.

👴 Recuerdo un tiempo antes de las Redes Sociales en el que la red era mucho más social y era habitual tener respuestas cuando preguntabas. Rememorando aquel entonces os lanzo esta pregunta que yo mismo voy a responder: ¿Cuál fue tu primera came?

En aquellos tiempos, cuando los foros php reinaban en el vasto imperio de Internet y este blog se llamaba «0,» (cerocoma.blogspot.com), era habitual tener respuestas de vosotras, personitas, ya fueran en comentarios, como en una entrada en otro blog que te hacía pingback o directamente con algo tan obsoleto como mandar un correo electrónico. Ahora lo llamaríamos red social federada y lo venderíamos como el futuro, pero lo de colaborar cada una desde su casa es más viejo que la orilla de la mar.

Eran tiempos bonitos, en los que hacerse viral era conseguir portada en barrapunto o meneame (u otros más de nicho como debug_mode=on), o si lo petabas mucho en slashdot. Yo tuve mi minuto de gloria cuando instalé Compiz (una innovación de los laboratorios de Suse que permitía prenderle fuego al escritorio o hacerle girar) en el Ubuntu de aquella época. Si buceas en el archivo del blog encontrarás algunos posts al respecto, pero no mucho más, siempre he andado de fracaso en fracaso (:

Eran tiempos de frikis donde a los fascistas se los trolleaba en el IRC y desde luego no se les consentía que tuvieran el control de absolutamente nada comunitario. El Javi de aquel entonces habría creído imposible la deriva autoritaria actual en la que estamos…

Pero recapitulemos que nos perdemos en memorias que no volverán: ¿Qué es una came? ¿Cuál fue tu primera, Javi?

Una came es una CAgada MEmorable. Una de esas que te hacen ponerte colorado cuando las recuerdas y no se la cuentas a nadie aunque hayan pasado más de (1, 2, 3… ¡wow!) unos cuantos años. Pues yo voy a hacerlo. Aireemos nuestras vergüenzas. ¡Os voy a contar mi primera came!

Corrían los dosmiles, hacia la mitad más o menos. Tendría que echar cuentas para concretar, pero es innecesario porque el NDA seguro que ya está caducado.

Yo tenía mi primer trabajo. Antes había sido becario, pero en aquel entonces ser becario no se consideraba un trabajo ni aunque te pagasen buenas perras. En mis primeros meses me dieron una tarea:

Hacer un proceso de recordatorio que enviase emails transaccionales a todos los investigadores que tuvieran facturas pendientes de revisar.

Esos eran todos los requisitos, tan escuetos como la documentación del producto, pero no había queja. Easy peasy lemon squeezy.

Eché un vistazo en nuestra base de datos de desarrollo a la tabla de las facturas y había un campo «revisada» con valores «S» y «N». En aquel modelado de base de datos era habitual que los programadores antiguos usasen campos string para booleanos, por lo que no me llamó la atención.

Maqueté la plantilla del correo e hice un proceso que recuperaba todas las facturas que no («N») habían sido revisadas con los correos de los responsables, rellenaba la plantilla y mandaba los correos.

Se lo enseñé al senior que me tutorizaba vigilaba en aquel entonces y me dijo «¿Funciona? Pues a producción». Probablemente hoy esté vibe-codeando por algún lado, ¡un abrazo si me lees! :_)

Un par de semanas después se desató el caos y llegó el drama. ¿Qué has hecho? ¡La que has liado! Sin saber cómo ni porqué me empezó a llover mierda y broncas de todo el mundo.

Homer Simpson avisando del fin del mundo

Al parecer, el campo «revisada» en la base de datos del cliente además de los valores «S» y «N», también guardaba valores «P». ¡El campo no era booleano! La «S» quería decir que la factura se había revisado y la «P» era que estaba pendiente de revisarse. ¿Y la «N»? ¡La «N» era que no tenía que revisarse! ¡Obvio! «¿Cómo has sido tan zopenco para no darte cuenta de algo tan evidente?»

Cómo dicen los guiris «long story short», nadie por encima del último mono (yo) asumió su parte y me tocó mandarle un correo de disculpas a todo el personal responsable del cliente al que le había mandado correos diciendo que tenían pendiente de revisar unas facturas que realmente no tenían que revisar y aprendí que no debía fiarme del trabajo previo de nadie, ni del mío mismo, porque hay muchos motivos por los que podría haberse hecho una marranada que no esté documentada en ninguna parte.

Y nada, esa fue mi cagada memorable, ponemos fin al modo abuelo cebolleta.

Esta es mi pequeña piedrita para recuperar las cosas buenas del viejo internet. También he añadido en el sidebar (o en el menú en pantallas estrechas) una lista de blogs de gente (BOFHer) con la que interacciono habitualmente, por si queréis seguir leyendo cosas frikis de informáticos.

Esa fue mi came, pero ¿cuál fue la tuya?

Desarrollo seguro: OWASP

Recientemente, he estado repasando los cursos que hay online, en universidades y en otras entidades sobre desarrollo seguro, viendo que casi todos se centran en OWASP (Open Web Application Segurity Project), lo cual está muy bien, pero se quedan en hablar del Top 10 de vulnerabilidades, y en realidad hay mucho más.
security photo

Está muy bien saber cómo se puede originar un fuego, pero es mucho más importante saber cómo actuar en cada caso o cómo se puede evitar que el fuego llegue a iniciarse ¿no? Con la seguridad en el desarrollo pasa lo mismo.

En el PDF que resume las vulnerabilidades, se pueden ver unos anexos con las responsabilidades de cada perfil (manager, developer y tester), y una pequeña guía para que una organización sea  segura. Esos anexos son muy importantes, puesto que nos ayudarán a ver si estamos haciendo las cosas bien o no.

Y bien, sabiendo los problemas que pueden surgir y la responsabilidad de cada uno para tener una empresa que practique desarrollo seguro ¿qué hacemos? Llegamos al que para mi es uno de los compendios más importantes que realiza este proyecto: OWASP Proactive Controls. En él se resumen las buenas prácticas que hay que realizar para funcionar de un modo seguro y evitar la mayoría de los incendios. Este es su propio Top 10:

  1. Verificar la seguridad pronto y a menudo
  2. Parametrizar las queries
  3. Codificar los datos
  4. Validar todas las entradas
  5. Implementar controles de autenticación y de identidad
  6. Implementar controles de acceso apropiados
  7. Proteger los datos
  8. Implementar logging y detección de intrusos
  9. Aprovechar frameworks y librerías de seguridad
  10. Manejo de errores y excepciones

¿Pones todos esos puntos en práctica? Sé que puede parecer difícil, pero profundizando un poco más, podréis ver que tienen también guías específicas de cómo hacerlo con cada tecnología, porque no es lo mismo estar haciendo una app para Android, que una web en PHP, y siguiéndolas podréis de un modo sencillo aseguraros de que estáis poniendo todo de vuestra parte para que vuestros desarrollos sean seguros.