Ayer comenzaba el plazo para rellenar la declaración de la Renta. Algunos usuarios, al previsualizar su borrador, pudieron acceder al de otras personas por accidente
A ver cuando salen los cuñados a decir que este tipo de errores lo solucionan en dos minutos aplicando alguna técnica de testeo: No señores, el desarrollo y puesta en producción de aplicaciones relativamente importantes exige muchos meses e inclusos años pero se ve que ni los cuñados ni los informáticos que gestionan la aplicación de hacienda lo saben.
En realidad es mucho más grave de lo que os pensáis... Desde siempre, si un usuario conoce la ruta de un documento de la AEAT, sólo con estar autenticado en la página podía ver dicho documento, aunque no le perteneciese a él.
#28 como es eso posible?, algun tipo de cache raruno?, algo tipo ... se guardan los pdfs con nombres "aleatorios" en algun sitio temporal y a veces se comparten porque es el mismo?... es bastante raro la verdad.
#32 Simplemente, no comprueban la cookie en el acceso a los documentos.
La ruta de esos PDF no es completamente aleatoria, se podría llegar a averiguar. Pero ojo, allá cada cual, recuerda que tienes que estar autenticado, y eso significa haber usado un método como un certificado digital, algo que garantiza el "no repudio" de lo que vayas a hacer, así que no podrás decir: "Fue un hacker"
#33 ¡Qué sabe nadie!
Dos días intentándolo y ha aparecido Bartolo con su flauta y ha sonado.
No creo que tenga nada que ver, pero es Firefox en Ubuntu.
cuando un usuario clicaba en el botón de previsualizar al mismo tiempo que otra persona que estuviera alojada en el mismo servidor, se podía ver su borrador en lugar del propio
No sé por qué me da que alguien ha puesto un "static" delante de alguna variable
Amazon Web Services [...], seguridad [...], leyes de EEUU [...], nada les impide ver tus datos[...], Azure lo mismo [...], no estaría tranquilo con mis datos en la nube [...]
#39 He trabajado para la administración y créeme, solucionar un fallo por muy tonto que sea me suele llevar entre 2 y 4 semanas salvo que el error sea muy grave y haya que tirar por la vía más rápida saltándose todas las normativas.
Arreglar un fallo es localizar el problema, documentarlo y solucionarlo: Eso, si es una tontería, me lleva un día, luego hay que pasarlo a los diferentes entornos de la aplicación (Desarrollo Cliente, Preproducción y producción). Cada entorno tiene sus propios horarios (bastante reducidos) de despliegue y hay una serie de personas que supeditan los cambios para tener la certeza de que no va a fallar nada (Salvo en el de desarrollo que ahí se fían de los desarrolladores). En algunos casos incluso vuelven a pasar todas las pruebas de estrés y pruebas unitarias en el entornos de preproducción para tener la certeza de que los cambios no van a originar otro fallo o van a hacer que el servidor caiga por una mala ejecución de código). Y te estoy hablando de entornos donde no debería haber fallos pero se dan por casos muy particulares o por cambios en algunos de los servicios empleados.
Y te estoy hablando de 3 entornos, tengo amigos que han llegado a pasar una aplicación (desarrollada para un cliente privado) por 10 entornos diferentes antes de ponerlo en producción: Estamos hablando de aplicaciones donde un mínimo fallo puede suponer millones al cliente (y por tanto a la empresa). Incluso en uno de los entornos tienen sistemas para medir la calidad del código y analizan los cambios efectuados para realizar sistemas de marcha atrás en caso que la puesta en marcha de nuevas funcionalidades/correcciones de bugs de problemas. En el momento que detectan algo raro hay que pasar al entorno anterior e incluso a empezar de nuevo para tener la certeza de que no va a haber problemas.
Por eso digo, que cuando veo que un usuario arregla una cosa en cinco es que la aplicación es muy sencilla o no dispone de un protocolo adecuado.
Edito: Lógicamente estoy hablando de empresas serias, a las cárnicas mejor ni acercarse.
#34 Me dices que con los datos de cualquier declaracion de hacienda del año pasado (no necesita certificado) un robot puede patearse todo un repositorio fisico de borradores de declaraciones?
Parece del pais de los memos, pero viendo que han implementado tan pobremente que dos peticiones concurrentes pueden colisionar en la vista del borrador...
#67 ¿Cambias el timestamp por un guid y ya está arreglado?
Ese sería el tipo de error que se soluciona en 2 min de testeo, yo apuesto por codigo spaguetti también.
El multihilo es jodido...
En este país, con una corrupción desmadrada, con un diferencial de riqueza enorme y en aumento, con aforamientos políticos, con falta de independencia judicial, con niveles gravísimos de impunidad, con una parte importante de la economía sumergida, con una ínfima persecución de delitos fiscales para grandes fortunas, etc., solo nos faltaba que violaran nuestros derechos a la confidencialidad de nuestros datos fiscales, para así animar a la gente para que cumpla con sus obligaciones tributarias.
Los directivos de las consultoras, seres importantes con traje y corbata, habrán cobrado millonadas de dinero público por la gestión mientras que los becarios que se han encargado de programarlo habrán tenido la suerte de trabajar gratis a cambio de "coger experiencia".
El típico error cuando no tienen un singleton factoría en la capa del servicio que te cree un hilo para hablar con la base de datos. A estas alturas, debería ser un error trivial de solucionar, siempre que el código esté bien mantenido por capas. Es un error mas comun de lo que se cree, en su momento me encontré el mismo error en la CECA, esa empresita que da servicio a prácticamente todas las cajas de ahorros de este país...
O sea, que se les ha ido de las manos y no saben como esconderlo
lopd-proteccion-datos.com/infracciones-y-sanciones
Esto es antiguo, pero no mucha gente lo conoce.
Haz la prueba y ya dirás.
La ruta de esos PDF no es completamente aleatoria, se podría llegar a averiguar. Pero ojo, allá cada cual, recuerda que tienes que estar autenticado, y eso significa haber usado un método como un certificado digital, algo que garantiza el "no repudio" de lo que vayas a hacer, así que no podrás decir: "Fue un hacker"
A ver si es cierto eso que dicen algunos de transparencia...
Yo soy el cuñado que dijo que la web de participación ciudadana de Madrid no cuesta ni la mitad de lo que han dicho.
Un error como este no se soluciona en dos tardes, porque el código será un infierno ilegible que no entiende ni el que lo hizo.
Dos días intentándolo y ha aparecido Bartolo con su flauta y ha sonado.
No creo que tenga nada que ver, pero es Firefox en Ubuntu.
No sé por qué me da que alguien ha puesto un "static" delante de alguna variable
wtf.
Es una incidencia mínima porque nuestra web es responsive y la abuela fuma. Es obvio.
twitter.com/ThePracticalDev/status/687672086152753152
twitter.com/ThePracticalDev/status/709371098694066176
Arreglar un fallo es localizar el problema, documentarlo y solucionarlo: Eso, si es una tontería, me lleva un día, luego hay que pasarlo a los diferentes entornos de la aplicación (Desarrollo Cliente, Preproducción y producción). Cada entorno tiene sus propios horarios (bastante reducidos) de despliegue y hay una serie de personas que supeditan los cambios para tener la certeza de que no va a fallar nada (Salvo en el de desarrollo que ahí se fían de los desarrolladores). En algunos casos incluso vuelven a pasar todas las pruebas de estrés y pruebas unitarias en el entornos de preproducción para tener la certeza de que los cambios no van a originar otro fallo o van a hacer que el servidor caiga por una mala ejecución de código). Y te estoy hablando de entornos donde no debería haber fallos pero se dan por casos muy particulares o por cambios en algunos de los servicios empleados.
Y te estoy hablando de 3 entornos, tengo amigos que han llegado a pasar una aplicación (desarrollada para un cliente privado) por 10 entornos diferentes antes de ponerlo en producción: Estamos hablando de aplicaciones donde un mínimo fallo puede suponer millones al cliente (y por tanto a la empresa). Incluso en uno de los entornos tienen sistemas para medir la calidad del código y analizan los cambios efectuados para realizar sistemas de marcha atrás en caso que la puesta en marcha de nuevas funcionalidades/correcciones de bugs de problemas. En el momento que detectan algo raro hay que pasar al entorno anterior e incluso a empezar de nuevo para tener la certeza de que no va a haber problemas.
Por eso digo, que cuando veo que un usuario arregla una cosa en cinco es que la aplicación es muy sencilla o no dispone de un protocolo adecuado.
Edito: Lógicamente estoy hablando de empresas serias, a las cárnicas mejor ni acercarse.
Parece mas que el identificador del pdf generado se basaba en un timestamp (mec error)
y la avalancha de solicitudes producia colisiones...
Parece del pais de los memos, pero viendo que han implementado tan pobremente que dos peticiones concurrentes pueden colisionar en la vista del borrador...
Ese sería el tipo de error que se soluciona en 2 min de testeo, yo apuesto por codigo spaguetti también.
El multihilo es jodido...
Y si es un obseso de la seguridad, 123456
Claro que si fuese para algo ya aún más serio, como desencadenar un holocausto nuclear: 00000000
- ¡Tranquilos, tenemos decenas de billetes!