Los inicios del lenguaje SQL (Structured Query Language) de consulta de datos se sitúan en el año 1986, cuando el Instituto Nacional Estadounidense de Estándares (ANSI) realizó una primera publicación de sus especificaciones sobre cómo operar con bases de datos relacionales. Sin embargo, no fue hasta el año 1999 cuando este lenguaje se convirtió en lo que se conoce actualmente, esto es, cuando se añadieron expresiones regulares y la posibilidad de realizar consultas recursivas.
Comentarios
Cuando un compañero investigador de Forristal envió un mensaje a Microsoft explicando el problema que habían descubierto, su respuesta fue bastante hilarante: “lo que nos describe usted no es un problema, así que no se preocupe por hacer nada para solucionarlo”
Merece un lugar destacado en el podio de los fenómenos. Justo al lado del que les dijo a los Beatles que la "guitar music" no tenía futuro.
#1 Jajaja que buena comparación hiciste amigo
#1 Realmente no es un problema de la base de datos. Tú le pides una consulta y te la da. La base de datos funciona perfectamente. El problema es la aplicación que la usa que no construye las consultas de manera segura. Esta vez Microsoft tenía razón.
#3
Por eso en Microsoft llevan años sacando parches para evitar vulnerabilidades de SQL Server accesibles a través de SQL injection. Porque no es un problema...
#4 como te han dicho no es un problema de SQL. Es un problema de la aplicación que hay por encima. El SQL funciona perfecto.
#6 ¿Quién ha dicho que sea un problema de SQL? ¿Has leído el artículo?
El correo describía una técnica desconocida hasta entonces, la SQL injection, que supone una puerta de acceso a innumerables exploits. La propia Microsoft ha lanzado quién sabe cuántos parches para reparar vulnerabilidades accesibles a través de ese mecanismo.
El correo no informaba de un "bug", sino de una técnica que podía poner en peligro (como ha hecho desde entonces) a muchos sistemas. ¿Cómo no va a ser un "problema"?
#3 No. Tal vez sea cierto que la SQL injection no es estrictamente un problema de la base de datos, pero Microsoft debería haber dado al problema la importancia que tiene, y haberla derivado al menos "a otra ventanilla". Hay muchos otros componentes afectados que también intervienen en el acceso a una base de datos que también son responsabilidad de Microsoft: ADO.Net, ODBC, WCF... Se podía haber intervenido en muchos niveles.
#1 La típica excusa de "No es un bug es una feature".
#5 no, no es eso, el problema es del desarrollo de la aplicación que corre sobre el servidor de aplicaciones y no del servidor de aplicaciones en sí o de la base de datos, de ahí la respuesta.
Vamos la culpa es del de desarrollo y no del de sistemas
#7 No en este tipo de inyección.
El problema del que hablan de 1998 y que sigue vigente es que SQL Server permite ejecutar múltiples sentencias concatenadas en la misma petición dinámica, esto con otras bases de datos no se puede, Oracle no te deja, MySQL lo tiene desactivado por defecto, por ejemplo. En Microsoft, refiriéndome a mi comentario anterior, siempre han dicho que es una "feature" porque cambiar ese comportamiento rompería muchas aplicaciones, lo que puede ser razonable, pero lo que ya no lo es tanto es que no pongan una puñetera opción de configuración por si quieres desactivar, o mejor hacer como MySQL y tenerlo desactivado por defecto y el que lo necesite de verdad que lo active.
Vamos que es algo como lo de que los usuarios de Windows se creaban en la época pre-Vista por defecto con permisos de administrador porque había aplicaciones que esperaban tener esos permisos.
Todo eso está muy bien, pero en seguridad la opción por defecto siempre debe ser la más restrictiva y que luego el que le venga en gana que relaje las medidas bajo su responsabilidad, por eso, y porque otras bases de datos viven perfectamente sin ello, es un bug de SQL Server.
En otros tipos de inyección cierto que la base de datos poco puede hacer, pero este no es uno de ellos.