Polarización

Me vais a perdonar porque abandone los artículos técnicos por un momento y os suelte una turra sociológico-política, pero es que últimamente entro mucho en twitter y me hierve la sangre más de lo que debiese, así que me voy a explicar un poco más calmado aquí que puedo poner todos los caracteres que quiera.

Imagen generada por la IA midjourney

Me podéis llamar progre (si, me gusta el progreso), izquierdista (si, creo que todos los humanos somos iguales y hay que hacer lo necesario para que la pobreza y la desigualdad no exista) e incluso me podéis tildar de rojo (no es mi color favorito, pero no tiene connotaciones negativas. En fin, que cada uno es como es y tiene opinión de casi todo (mejor si esta es informada). Tengo muchos y buenos amigos que son de derechas, de todos sus tipos, los hay muy cristianos, los hay liberales en lo económico y conservadores en lo demás, los hay que lo son porque es lo que escuchan en la tele (que tampoco han entrado a pensar mucho en ello, pero si lo dicen por algo será) y luego están los que son españoles ante todo y saben que los extranjeros son inferiores y han venido a quitar el trabajo a sus hijos (igual si se dedicasen a estudiar este riesgo no existiría…). Muchos de estos amigos son buenísimas personas y nada malvados, no dejaría de ser su amigo por nada del mundo.

El caso es que en el micro-cosmos de twitter y, según parece, en muchos medios de comunicación hay una tendencia increíble a evaluar los mensajes según su procedencia y catalogarlos como malos o buenos según si es de mi tendencia política o de otra. Hemos reducido la crítica a buscar las cosquillas a los que no son de nuestro bando, a pensar que los unos son unos demonios y los nuestros unos angelitos, y no, eso no es así. El espíritu crítico ha de guiar nuestros pensamientos siempre, tenemos que librarnos de estereotipos, de buscar segundas intenciones. Tenemos que leer los mensajes, analizarlos y decidir si estamos de acuerdo o no en conciencia, no como miembro de una tribu, sino como ser humano con nuestra conciencia y nuestras contradicciones.

No voy a poner ejemplos aquí, solo tenéis que leer las cuentas de zascas (que también se han polarizado en una de zascas a la izquierda y otra de zascas a la derecha) para ver que la coherencia no existe en ningún sitio y que los mensajes que mandamos al contrario no nos los solemos aplicar (ver la paja en ojo ajeno). Lo que si os pido, seais rojos, morados, azules o verdes es que intentéis mirar el mensaje primero y el emisor después y un último consejo (de los que vendo y para mi no tengo)… Recuerda que no siempre tienes la razón. Escribir el último tweet no te convierte en el ganador, solo en el que se ha cansado más tarde.

Como evitar perder la sesión cuando navego por un iframe

Recientemente he tenido un proyecto de página web que funcionaba perfectamente cuando se hacía directamente en el navegador, pero cuando intentaba meter el contenido en un iframe para integrarlo con otra parte de la web no conseguía que se mantuviese la sesión. Esto, además de un malestar insidioso, me produjo curiosidad, ya que hacía mucho que no utilizaba iframes y, parece, que la forma en que tratan estos ha cambiado un poco con las últimas versiones de los navegadores.

Aunque podría deciros la solución ya mismo, vamos a darle un poco de dramatismo y os voy a explicar porqué un iframe no se comporta exactamente igual que la navegación en el browser y como eso hace que puedas perder la sesión.

Imagen explicativa

¿Cual es la diferencia?

Un iframe no es más que un marco que se inserta dentro de una página web y cuyo contenido es cargado de una dirección distinta de internet, eso tiene la ventaja de que puedes enriquecer la página con contenido que no tienes que generar desde tu servidor, o que puedes reaprovechar cosas que ya tienes hechas en otros sistemas y el usuario podría no notar que esa parte del contenido proviene de otro sitio. Precisamente por este detalle (que los usuarios no son conscientes de donde viene ese contenido) se abren posibilidades de ataques Cross Site Request Forgery (CSRF), que significa que podrían recuperar una cookie de un dominio distinto desde una iframe, por ejemplo, y secuestrar la sesión original o cualquier credencial de usuario que viaje con las cookies.

Precisamente para evitar estos ataques en 2016 se estableció un atributo para las cookies (SameSite) que prevenía que se pudieran enviar cookies a dominios distintos de los que se estaba navegando (de lo que veíamos en la barra de navegación). Los posibles valores de estos atributos son:

  • None: las cookies se mandan a todos los dominios.
  • Strict: Las cookies solo se enviaran al dominio que coincide con el de la barra de direcciones
  • Lax: Las cookies se enviarán al contexto principal y con las navegaciones de primer nivel.

Antes de tener este atributo todas las cookies eran tratadas como si fuese None y los iframes podían recibir las cookies (entre ellas las de sesión), pero a partir de que los navegadores adoptaron el atributo, la cosa cambió y ahora si la cookie no declaraba el SameSite se consideraba que este era del tipo Lax y esto hace que la navegación dentro de un iframe que está en otro dominio no pase las cookies.

¿Cómo arreglarlo?

Básicamente lo único que tienes que hacer (esto ya depende mucho del framework que tengas) es declarar las cookies con este encabezado:

Set-Cookie: session=your_session; SameSite=None; Secure

Con esto declaramos que las cookies podrán ser retransmitidas, pero además que solo se transmitirán a dominios seguros (con https). Esta pequeña modificación hace que se pueda navegar ya dentro del iframe, pero, ¡cuidado! te añade un potencial problema de seguridad CSRF.

Cerrando el 2021

Dentro de dos meses hará 15 años que llevo manteniendo este blog, una eternidad en cuestión de tiempo tecnológico y una eternidad también en tiempo biológico. Generalmente se usa este último día del año para hacer un resumen de lo que se ha hecho y se ha dejado de hacer en el año saliente y dar la bienvenida a los nuevos planes y deseos para el año que entra… Bien, hoy no estoy de humor para ello (que eso no quita que no lo haga en algún momento), mi retrospectiva será más de estos 15 años de blog que de este año de pandemia continuada. Es más, se cumplen ya 20 desde que se publicó algo bajo este dominio… Y eso requiere un poco de historia.

Compré el dominio yoprogramo.com allá por 2001 poco después de haber contratado mi adsl con terra y con el ánimo de poner una web informativa sobre temas de programación. Yo, como muchos sabréis, me defino como programador, un programador con vocación empresarial y con muchas ganas de hacer cosas útiles por todo el mundo. De hecho, si sentís curiosidad, hay entradas de la web en Internet Archive (os muestro la primera de todas de Agosto de 2001):

En aquel momento firmaba como JaeSoft (Jose Antonio Espinosa) ya que lo que más deseaba era crear mi propia compañía de desarrollo de software, aunque por aquel año yo estaba en otra empresa (Sema Group – SlumbergerSema – Atos) haciendo cosas muy complicadas y muy interesantes para la época.

Intenté reunir personas interesadas en programar y en escribir, muy pocas se apuntaron y mi interés por mantener tantas secciones, incluyendo noticias, trucos y demás cosas que podrían servir para configurar un portal se resintió un tanto cuando perdí parte de los contenidos (aquí una imagen para que veáis como era la cosa en 2004 después de recuperar algunos):

A partir de ese año cambié mi rumbo laboral, abandoné la multinacional en la que había trabajado y me puse por mi cuenta. La web sufrió un hackeo en que, afortunadamente, no perdimos nada (pero publicamos el artículo) y la web pasó a estar patrocinada por la nueva empresa que acababa de fundar (Digimate Computer)… Incluso patrocinaba la web más loca que nunca he publicado, una que se llamaba «quiero mi wii» que me ayudo a conseguir una consola wii en un momento en el que había una escased tremenda de ellas. Fue tanta gente la que quería la wii que tuvimos una avalancha de visitas el poco tiempo que estuvo activa:

Hasta que un día de 2007 decidí cambiar de formato, abandonar el portal para el programador que, aparentemente, no usaban demasiados programadores y me daba muchísimo trabajo mantener y creé (utilizando un wordpress que había aparecido el año pasado) mi blog personal.

Y si hace 15 años que llevo escribiendo en este mi blog, puedo seguir escribiendo algunos más… Intentaré estirar lo más posible mi dedicación al mismo durante este año entrante y, finalmente, os deseo a todos que el año 2022 os sea propicio. Desear es gratis, pero es una buena cosa para variar…

Feliz 2022

log4j, las vulnerabilidades, los parches y la sobre-ingeniería

Durante estos días si te dedicas mínimamente a esto de la informática y has creado algún sistema con Java habras sufrido el problema del log4jshell. Si es que no, pues te lo explico:

log4j es una librería de Java que lleva existiendo desde hace innumerables años y que es muy utilizada para registrar los eventos que tienen lugar en un sistema y poder controlar qué se registra y qué no. Pues bien, la versión 2 de esta librería incluía funcionalidades para hacer sustituciones en las cadenas que se guardan en el log y, continuando con la tradición más añeja de Java, se les ocurrió que sería buena idea que esas cadenas a sustituir pudiesen hacer llamadas a sistemas externos y recibir objetos completos. Utilizando el estandar jndi permitían incluso hacer llamadas RMI o acceder a servidores LDAP. Supongo que el programador que añadió estas funcionalidades vería su utilidad en algún momento, pero también es cierto que yo nunca he visto a nadie usarla.

En fin, que esto llevaba ahí un tiempo y a algún «hacker malvado» se le ocurrió probar qué pasaba si en la url que le pasaba a la cadena a loguear incluía la dirección de un servidor que él controlaba y que permitía descargarse un objeto que hacía «cosas malas» en el sistema… Y la prueba funcionó y en cuanto alguien se dió cuenta que había cadenas extrañas que empezaban por ${jndi:ldap:// y que provocaban funcionamientos anómalos se dio la voz de alarma y se creó un registro de vulnerabilidad (CVE-2021-44228) y con un exploit super-sencillo y que mostraba que había cientos de miles de sistemas afectados.

El parche a esa vulnerabilidad llegó pronto (y eso que log4j está mantenido solo por voluntarios) y mucha gente se pasó buna parte del fin de semana parcheando los sistemas (alguno tardó algo más), aunque sin tener muy claro si el sistema había sido comprometido y modificado antes, cosa que requiere otras medidas adicionales y muy costosas. A día de hoy se ha encontrado que el parche que se hizo no contempla todos los casos y se ha registrado otra vulnerabilidad (CVE-2021-45046) que requiere otro parche… Parches, que, al fin y al cabo lo único que hacen es deshabilitar esa funcionalidad que, en algún momento, a alguien, le pareció interesante.

Son incontables el número de horas que el personal de IT (desde programadores hasta técnicos de sistemas) se han dedicado a tapar este agujero (y seguro que habrá muchos agujeros sin tapar todavía). Eso se traduce en muchos millones de Euros de dinero gastado sin sentido… Y todo porque a alguién «le pareció una buena idea esa funcionalidad» y porque todo el mundo usa componentes que no conoce, en los que «confía», aunque no poga un duro para su desarrollo…

Por cierto… Hay por ahí ya los «negacionistas de los parches» que van diciendo que si los parches son malos, que no saben lo que hay dentro, que todo es parte de una conspiración y esas cositas… En fin, el ser humano es lo que tiene (o no).

ACTUALIZACIÓN 17-12-2021: Hay todavía otro parche que meter, el 2.17.0 ya que hay una cadena especial que puede dar como resultado un DDoS… A ver lo que nos dura.

node.js: no, no y no…

Llevo en esto de la programación desde que tenía 11 años (y ya tengo casi 51) por lo que he tenido que aprenderme muchos lenguajes y trabajar con muchos entornos en mi carrera (Vale, de los 11 a los 18 todo era BASIC, pero luego…). Por poner un ejemplo, aprendí C en 1989 y sigo usándolo a día de hoy ¡Bendita IoT! y siempre he sido partidario de respetar todos los lenguajes y todos los entornos, ya que si alguien se ha tomado la molestia de crear un nuevo lenguaje, bueno, pues por algo será…

Lo que vengo a decir aquí es que no todos los lenguajes, frameworks o entornos sirven para todo y eso es algo que hay que evaluar antes de meterse a implementar un proyecto con todo lo que ello conlleva. Yo, particularmente, he hecho proyectos (que algunos siguen en producción a día de hoy) en casi cualquier lenguaje, desde cy c++ hasta Dart pasando por objective-c (sniff), java, javascript, python, php, swift y cosas más raras con usos más limitados (mira que se han hecho maravillas con ruby y no le encuentro todavía el punto), el caso es que no tengo una especial predilección por ninguno y programo en lo que creo más adecuado para el proyecto… Y aquí viene el tema, si quieres hacer un proyecto que envejezca bien NO LO HAGAS EN NODE

Entendedme bien, el concepto de node es brillante, el tomar un lenguaje construido en base a ñapas, una encima de otra, que tarda decenios en estandarizar las cosas más básicas y que tiene a una legión incansable de programadores generando frameworks y librerías que se pueden medir en frameworks por hora y sacarlo del navegador me parece bien. Hacer un repositorio central del librerías que cualquiera puede utilizar y que permita respetar las dependencias me parece bien también y te permite hacer cosas muy complejas en muy poco tiempo… Eso si, no quieras hacerlas durar en el tiempo…

Yo no tengo muchos proyectos en node (¡Gracias a Dios!) pero os pondré como ejemplo uno que terminé hace tres años… O eso creía yo. Es un proyecto hecho en node para el escritorio, que usa electron como motor (y se han hecho cosas simplemente magistrales con electron, como visual studio code) y unas pocas librerías de criptografía y acceso a blockchain (si, habéis acertado, es una aplicación de criptomonedas). Este proyecto, muy bien programado y probado en 2019 lo dejé aparcado (pero disponible para quien quisiera usarlo) y con el boom de las criptomonedas en 2020 quise volver a usarlo… Pero resulta que no solo ya no compilaba sino que no ejecutaba porque las librerías subyacentes se habían actualizado y sin ningún criterio de compatibilidad hacían que objetos que antes tenían ciertos métodos ahora no los tuviesen o la forma de llamar a las cosas en alguna librerías fuesen distnitas… Bueno, cosas que pasan, me pongo a intentar actualizar las dependencias de esas librerías y a cambiar el código afectado (cosa nada fácil lidiando con un año de cambios en el universo js) y consigo volver a compilar y empaquetar el programa (mediados de 2020)… Dejamos todo funcionando y, como somos gente de pocos recursos y trabajamos lo justo con criptomonedas, no volvemos a tocarlo hasta hoy… Dia en el que me encuentro que una librería de mi sistema no funciona con el electron de antes… Y el electron nuevo ha cambiado cosas fundamentales que me obligaran a cambiar todo el código… Y ya no se si estoy con ánimos para hacerlo.

Y esto es así porque el sistema de npm y node no exigen nada a nadie y hay muchos programadores (muchos más en el mundo js que en el resto del universo conocido) que tienen la santa manía de refactorizar cosas y no pensar en el mantenimiento de lo que se ha escrito sino en la virguería que se conseguirá con la siguiente versión…. Así pues, si queréis crear un sistema mantenible que no tenga que actualizarse cada semana con las últimas librerías y tengas que estar investigando qué es lo que han cambiado los mantenedores de ese paquete, por faor, usa cualquier otra cosa que no sea node

Para un prototipo está bien, para todo lo demás, usa algo distinto.