Tres historias de terror como desarrollador para Halloween

🎃 Eliminé una base de datos en producción

Ana tenía menos de un año de experiencia como programadora.

Su jefe en aquel tiempo administraba múltiples sitios de clientes, sobre todo landing pages. Era un fanático del shared hosting, puesto que todas las opciones para configurar el “servidor” se encuentran allí a través de una interfaz web y casi no hay que utilizar la terminal, gran error a largo plazo en mi opinión.

El jefe compartió con Ana accesos a la base de datos, y como Ana no quería utilizar phpMyAdmin que venía en Cpanel, utilizó un software de Mac en esta ocasión.

Al momento de abrir el programa, hizo un listado de todas las tablas sin ningún problema. Ejecutó algunas consultas para saber si la conexión funcionaba correctamente.

Ese día no hubo problemas, lo peor vendría un par de semanas después.

Su jefe le pidió eliminar unos registros de clientes de forma manual. Sí, no usaban un soft delete, así que eliminar los registros para siempre de la base de datos era la única opción viable.

Entre las instrucciones a la base de datos que tenía guardadas para su entorno local, tenía el clásico delete purchases from. Copió y pegó la consulta, pero cuando trataba de editar los parámetros de filtro, presionó Ctrl + Enter.

5300 registros actualizados. 30ms

Y ahí se dio cuenta de que había cometido un error. Cuando refrescó la tabla, todo se había perdido. Además, era una tabla que no tenía dependencia sobre otras, ni siquiera un error de clave foránea la pudo salvar.

Procedió a llamar a su jefe. No se molestó, pero sí le comentó que asumía que en cualquier momento podía pasar. Su jefe usó una copia automática de seguridad de la noche anterior y, como era un sitio no tan utilizado, procedieron a usar el script SQL para eliminar, crear y rellenar la base de datos otra vez.

Como era junior, ella estaba muy asustada, pues pensó que ese sería su último día en la empresa y que no había nacido para ser programadora en esta vida.

Pero todo se arregló, y desde ese momento Ana fue diez veces más cuidadosa con cualquier script que necesitara ejecutar en una base de datos.

Medidas de precaución

• En todas las bases de datos para entornos de producción, trata de crear una conexión de solo lectura. Esto te ayudará a evitar ejecutar instrucciones no deseadas por accidente.
• Si usas un software con interfaz gráfica (GUI) para conectarte a una base de datos, agrega siempre un color de fondo a tus conexiones. Personalmente suelo utilizar el siguiente rango de colores: verde para bases de datos locales, amarillo para versiones de staging o QA y rojo para bases de datos de producción. Si tengo una versión de solo lectura para producción, suelo utilizar el color naranja.
• Trata de usar siempre soft deletes como medida de borrado. Usualmente es un campo llamado deleted_at (eliminado_a_las). El valor NULL se interpreta como que el registro está activo. Si está eliminado, tendrá un valor con la fecha y hora en que se procedió a eliminar. Sin embargo, tu lógica de aplicación debe soportar ocultar estos registros al usuario final.

🎃 Un e-commerce hackeado

Hace varios años, un compañero de un antiguo trabajo refirió a Max a un cliente con un sitio Wordpress desarrollado por una agencia de desarrollo.

La historia de terror no era que el sitio tenía incluso el core de Wordpress modificado (dios mio), sino que aparte el código de los propios plugins estaba modificado, lo que hacía imposible aplicar una actualización futura sin miedo a romper todo.

Al pasar los años, se pudo migrar hacia un software a medida, realizado con un framework. Después de la migración, todo estuvo bien por un año entero.

Hasta que un día la dueña del sitio llamó a Max.

• Max, nos han hackeado
• No hay hackeos, sólo brechas de seguridad desde el lado del usuario - respondió Max, asumiendo que tal vez alguien había compartido su contraseña por error.
• ¡Mira el sitio web! ¡Está lleno de imágenes en ruso!

Y era verdad, habían reemplazado las imágenes de productos y banners call to action del sitio web con un montón de propaganda que Max no entendió ni quiso entender.

• Oops - dijo Max al observar el daño.

Max procedió a bloquear el sitio web. Entró con SSH al servidor y no hubo ningún tipo de archivo extraño o codificado que le hiciera sospechar que tenían acceso a la base de datos. Después de un rato de seguir pensando por donde pudo haber entrado el intruso, sólo llegó a una conclusión.

“El panel de administración para subir imágenes”

Y confirmando con los trabajadores, resultó que para acceder rápidamente al panel de administración, habían cambiado la contraseña a una simple, como “test123”.

No se perdieron imágenes, ya que estaban subidas a un almacenamiento de objetos (similar a AWS S3), y cuando se reemplazan las imágenes NUNCA se eliminan. Esto para emular la característica de versionado que AWS S3 tiene.

Max nos envía también las medidas de solución y futuras precauciones para evitar posibles fallos.

Medidas de precaución

• Se cambiaron todos los password por una versión más complicada de ellos, de momento eliminé la opción de cambiar la contraseña para todos los tipos de usuario.
• No permitir a la aplicación de eliminar las imágenes una vez usadas. Siempre almacenar las cosas fuera del servidor.
• La base de datos también estaba fuera del servidor, eso permitió volver a una versión de 3 horas antes del incidente. Se perdieron algunos registros de algunas compras, pero ya estaban guardados en un software externo de facturación.
• Divide a los usuarios que pueden actualizar la información del sitio con roles y permisos. Con esto igual los atacantes no tuvieron acceso a la información de los clientes.

🎃 Sin dinero, tuve que despedir a los desarrolladores

Allá por el año 2017, Juan tenía a su cargo un par de desarrolladores junior. Trabajaba en ese momento para una startup. Recibió fondos de Venture Capital y las ventas iban “ajustadas”.

Fue entonces cuando descubrió que, cuando las empresas no consiguen dinero, es difícil mantener un sueldo estable para todos los trabajadores.

Es difícil despedir a alguien de una empresa. Como cofundadores, nos enorgullecemos de que nuestros trabajadores amen nuestra empresa, olvidando que también lo hacen para mantener a una familia, pagar la hipoteca de una casa o un carro, etc.

Tras una racha de más de 3 meses sin alcanzar las ventas esperadas, Juan y sus socios decidieron despedir a los desarrolladores que habían estado contratados por un período de 6 meses.

Los otros dos cofundadores le dijeron a Juan que él sería el responsable de comunicar tal decisión, ya que aún no contaban con un encargado de recursos humanos.

Juan llegó un viernes y les comunicó la noticia a ambos desarrolladores. La expresión de ambos fue de decepción total. Juan pudo entender en parte, ya que desconocía las situaciones difíciles por las que cada uno podía estar pasando.

Lo máximo que pudo ofrecer fue preparar una carta de recomendación.

No hay medidas de precaución escritas por Juan, pero desde el lado del negocio creo que me siento en la libertad de escribir algunas.

Medidas de precaución

• No contrates más de lo que puedas mantener. Existe una frase popular: “contrata despacio, despide rápido”.
• No hagas promesas exageradas a los trabajadores; muestra positivismo, no mentiras exageradas. Es mejor decir: “Somos una startup, qué tan lejos lleguemos depende de nosotros” en lugar de: “Vamos a ser lo mejor de este país, vamos a llegar a la luna”.
• Como fundador, recuerda que confiar tu empresa a tus trabajadores es como darle a un extraño el cuidado de tu hijo. Nadie la amará más que tú.