Como ya sabéis los que lleváis tiempo por estos lares, me gusta revisar muchas de las cosas que hacemos y que tienen que ver con la tecnologías web revisando los activos de Apple.com. Lo hago porque siempre se han mostrado amables cuando les hemos reportado cosas, y porque su estructura es lo suficientemente grande como para que siempre haya algún servidor con una característica concreta similar a la que esté probando.
Cuando sale alguna cosa seria, se lo reportamos para que lo tenga en cuenta. Cuando es poca cosa, sirve para aprender un poco más. En el pasado os he hablado de los servidores de LifeRay en Apple, de los detalles en la configuración de los mensajes de error en los servidores web, de las búsquedas de Poodle o de la localización de los errores de IIS Short Name en servidores de Apple.com.
Cuando sale alguna cosa seria, se lo reportamos para que lo tenga en cuenta. Cuando es poca cosa, sirve para aprender un poco más. En el pasado os he hablado de los servidores de LifeRay en Apple, de los detalles en la configuración de los mensajes de error en los servidores web, de las búsquedas de Poodle o de la localización de los errores de IIS Short Name en servidores de Apple.com.
Figura 1: Algunos backups de Apple son de una extensión "Original" |
Hoy domingo, solo os quiero traer un detalle que tiene que ver con una mala práctica de algunos administradores de sitios web de Apple.com, y es la forma en la que hacen backup "rápido" de ficheros en la web. Estos backups suelen ser un problema de seguridad en las aplicaciones web de muchas organizaciones, ya que son los que hacen sin seguir ninguna política de seguridad, para hacer un cambio rápido. A veces son carpetas comprimidas, otras simplemente copias de ficheros renombrados que se hacen en la misma carpeta, por si el cambio falla poder volver a dejar todo como estaba.
Figura 2: Alerta de Faast de backups con extensión ORIGINAL |
En estas situaciones, un programador web va a hacer un cambio en un archivo, y por si falla, copia el archivo original y le pone una extensión como .backup, .2, o el famoso .old. Todos estas extensiones van, por supuesto, en las herramientas de fuzzing en servidores web. Hace el cambio, y si luego todo va bien, se debería borrar el fichero de backup. La realidad es que esto no pasa siempre, y al final es común encontrar estos ficheros de de backup rápido en muchas páginas web. La gracia está en que un fichero PHP o JSP con una extensión como .BAK no es ejecutado en el servidor web y por lo tanto se puede acceder en muchos casos al código fuente del backend.
Figura 3: En algunos repositorios OpenSource se usa la misma extensión |
En Apple, jugando con Apple.com, no saltó en nuestro sistema Faast que es común que utilicen la extensión .ORIGINAL para hacer estos backups rápidos. De hecho, buscando con Google es posible localizar en los repositorios de OpenSource de Apple.com o algunos ficheros en los que se hace exactamente lo mismo.
Figura 4: Comparación online de las diferencias en los textos de las dos URLs |
Utilizando un comparador online se puede ver qué cambios hay en los textos - en este caso no hay código de backend - entre las dos páginas que he probado:
- http://www.apple.com/pt/internetservices/terms/sales_policies.html
- http://www.apple.com/pt/internetservices/terms/sales_policies.html.original
Por supuesto, si eres programador web o administrador de sitios, no dejes ninguna copia de de estos backups rápidos - sea la extensión que sea - en ningún lugar. Apple tampoco debería dejar ninguna de estos ficheros "originales" en el servidor, ya que en cualquier momento un error de estos puede llevar a algo mucho más peligroso.
Saludos Malignos!
Lo que yo haría es tener una copia de todo el sitio en un PC propio, ahí estarían los .bak ocasionales. Y luego de probar bien todo subir los archivos modificados, y no los .bak, al servidor. Lo que intuyo que ocurre es que los sitios de Apple deben tener una galaxia de archivos haciendo difícil que cada empleado tenga una copia local de todo el sitio, además de que puede haber una restricción en el contrato que les prohíba hacer eso.
ResponderEliminarLo otro que se me ocurre es tener una versión _dev, que consista en una copia del sitio entero, alojada en el mismo servidor, y que sea donde se hacen los cambios, luego de probado todo se actualiza la versión pública. Puede ser que esto tampoco sea práctico para las grandes empresas.
Yo trasteo en un servidor exclusivo para desarrollo, una vez que el código es funcional y testado, se implementa en el servidor web. Pero he encontrado .old en servidores de antiguos compañeros... Y cosas peores olvidadas ahí, que hoy por hoy es un coladero de los grandes.
ResponderEliminarGracias por el artículo.