Portada
mis comunidades
otras secciones
#1:
No es una vulnerabilidad en SQL
Es un SQL injection que no es lo mismo.
Es un SQL injection que no es lo mismo.
#9:
#4 yo he heredado un proyecto que se traga inyecciones en todas las partes del código, sin ningún tipo de control. Lo más que habían limitado era a nivel de base de datos que no acepte dos consultas en una, es decir, no sé podía meter una inyección cerrando el select y metiendo un update a continuación porque la base de datos no acepta eso. Y diría que viene así por defecto, no es que hayan hecho algo.
Y todo esto de una empresa tocha como es Seidor.
Y todo esto de una empresa tocha como es Seidor.
Comentarios
No es una vulnerabilidad en SQL
Es un SQL injection que no es lo mismo.
#1 Pero la sql injection, no es culpa de sql, sino de la calidad de la programación de la app y sus servicios.
Qué falaz
#1 gracias por el comentario. menudos periodistas
Dejo el típico chiste y me voy
#2 Y el otro chiste que falta:
#22 Ha votado positivo
bobbytables seal of approval
#2 Yo venía a esto mismo. Gracias por ahorrarme el trabajo
#2 Yo iba a decir que también la puerta permite acceder al avión y no he visto que se queje nadie.
Pasamos del "Drop table" al "Drop plane"
#7 mucha tela envolver un avión.
Perdón.
Diria que ya lo he visto por aquí. Del blog de Chema alonso
Juraría que es duplicada
Cómo convertirse en Tripulante Aéreo Autorizado con un SQL Injection Level 1 (y saltarse las colas de seguridad de los aeropuertos)
Cómo convertirse en Tripulante Aéreo Autorizado co...
elladodelmal.com#0
#13 Consultas parametrizadas y verificación de los parámetros de entrada antes de ejecutar la consulta. Es de primero de programación.
#24 Putos O'Brian...
Lo que ha fallado es esta web, que gestiona tripulaciones y asigna servicios. Es decir, que podrían colar a alguien en la aeronavem que no es poco, pero...
https://www.flycass.com/
Por el titular parece que se han hecho con el control de la aeronave directamente
#15 Pues porque no han ido más allá del ordenador, porque poder podían.
¿Pero como te pueden hacer una inyeccion SQL en el 2024?
Eso quedo anticuado hace 10 años
#4 supongo que el temaa de los aviones es como los bancos, los trenes o el metro, algo tan delicado que no puedes cambiar de tecnología cuando quieras
#5 Pero siempre se puede envolver
#5 No es necesario cambiar de tecnología. Con hacer comprobaciones de la entrada de datos por parte del usuario, ya se puede evitar.
#5 El tema es que la vulnerabilidad parecía estar en la web, no tiene que ver en sí con los aviones ni el control de acceso a cabina, ni con los sistemas del aeropuerto. Lo que han vulnerado es la base de datos a la que acceden estos sistemas, por varios motivos, que la web era vulnerable a inyección SQL, y porque el resto del sistema no tenía control de permisos.
cc/ #4
#4 Trabajo con una aplicación legacy de 2007 que funciona con MySQL en lugar de Mysqli por lo que no se pueden hacer consultas preparadas ni escapar caracteres. Es un auténtico coladero de SQL inyección.
Y no quiero dar más pistas pero seguramente tu coche lo hayas comprado gracias a esa aplicación.
#8 Pues cambiar mysql_ por mysqli_ es trivial. No será que no habéis tenido tiempo...
#8 que no se puede escapar caracteres? Ya en 2007 eran sobradamente conocidas las inyecciones SQL, y da igual que uses para conectar a la base de datos, siempre hay forma sencilla de evitar las inyecciones. Normalmente es tan simple con un .replace(...).
Y luego está lo que dice #18, no es difícil el cambio.
#18 es que es un desharroyador
#8 que funciona con MySQL en lugar de Mysqli por lo que no se pueden hacer consultas preparadas ni escapar caracteres
¿ Quién te impide escapar caracteres ?
¿ Qué te impide limpiar la entrada de datos y validar su contenido antes de enviarlo a MySQL ?
Las inyecciones SQL llevan con nosotros desde bastante antes de 2007, lo único que cambia mysqli es que facilita la entrada parametrizada, pero ya desde antes se controlaban estas cosas.
De hecho, existen inyecciones SQL mucho más complejas que esta de las comillas, y sólo con parametrizar no te vale, escapar caracteres y otras estrategias nunca están de más.
#4 yo he heredado un proyecto que se traga inyecciones en todas las partes del código, sin ningún tipo de control. Lo más que habían limitado era a nivel de base de datos que no acepte dos consultas en una, es decir, no sé podía meter una inyección cerrando el select y metiendo un update a continuación porque la base de datos no acepta eso. Y diría que viene así por defecto, no es que hayan hecho algo.
Y todo esto de una empresa tocha como es Seidor.
#9 cuidadin con el tema del secreto industrial.
#9 Seidor y RCD Español, todo un hit en su día. Les acaba de comprar un fondo de inversión de USA, harán lo mismo a mayor escala, Carlile.
#4 Anticuado?
basta con que cualquier proceso coja parámetros y los meta directamente en la query.
Aquí la única vulnerabilidad que ha habido es un código antiguo, del estilo "si funciona no lo toques" que ha permitido inyectar la vieja receta donde por código y sin comprobar nada, se construye la parte WHERE de la sentencia de SQL y se lanza alegremente. Después unas simples comillas en el formulario de entrada en el nombre de usuario o la clave hacen la magia. Ni ha habido vulnerabilidad en el lenguaje (seguramente PHP) ni por supuesto en la tan limitada como potente sintaxis de SQL.
Veredicto: artículo de mierda.
Justo ahora que he agotado las vacaciones salen viajes gratis
Como siempre noticias de seguridad un poquito sensacionalista