¿Por qué el uso de la inyección de SQL para extraer contraseñas o hashes de contraseña de una base de datos de inicio de sesión (que nunca debería divulgarlas legítimamente) es incluso posible?

Hay una gran brecha entre "no requiere" y "implementado por el licitador más bajo".

  

¿Por qué incluso usamos software de base de datos de gran potencia y consultas SQL?

Porque si ya está ejecutando una base de datos SQL para sus datos transaccionales, la implementación de una segunda pila de tecnología con un personal de desarrollo y apoyo debidamente capacitado para una función muy específica es muy costosa.

Dado que no pueden obtener una pila de aplicaciones correctamente, ¿cómo van a hacer frente a dos?

Es cierto que el problema de la inyección de SQL surge de las API que no separan el código (SQL) de los datos (parámetros) mientras que hay otros sistemas de base de datos (y API de SQL) que hacen cumplir esta separación. Pero las bases de datos relacionales y las bases de datos SQL en particular, proporcionan una gran cantidad de funcionalidades que simplemente no están disponibles en los otros tipos de bases de datos. Sería muy difícil escribir un carrito de compras que utilice LDAP para la persistencia.

En mi humilde opinión, las personas responsables de desarrollar este sistema son tan culpables como el pirata informático.

Otro ángulo para la respuesta de Symcbean.

Toda la situación parece bastante simplificada. ¿Quién debería hacerse cargo de lo que se puede consultar y de lo que no? ¿El DB subyacente (que usa tablas especiales para el almacenamiento de usuarios), el servidor de aplicaciones web o incluso un WAF? ¿Qué pasa con las consultas que incluyen declaraciones LIKE (es decir, PasswordHash como 'a%', puedes ver a dónde va esto)? Si vamos más lejos, la inyección de SQL no se trata solo de robar credenciales de inicio de sesión. Puede haber un montón de información más sensible que se puede extraer. Peor aún, puede llevar a RCE en el servidor DB. Y así sucesivamente.

Parece más fácil simplemente implementar medidas para evitar la inyección de SQL (por esto, por supuesto, no solo se trata de parametrizar sentencias de SQL, sino de todo el enfoque de defensa en profundidad para evitar la inyección de SQL).

por lo general, una tabla de usuario proporciona la asociación relacional al contenido en la base de datos real.

por ejemplo, usuario: jon_smith publicó esta publicación de blog

La tabla de usuario también es el lugar lógico para almacenar las credenciales de inicio de sesión. El problema / pregunta no es "por qué es una base de datos que almacena las credenciales de inicio de sesión", sino más bien por qué las personas no están almacenando los valores de contraseñas y comparando el valor con el que se autentica.

La respuesta simple es: desarrolladores malos / perezosos y gerentes de productos baratos que prefieren pagar £ 500 para que un estudiante o profesional independiente construya una base de datos para una elección en comparación con un desarrollador de software profesional

  

Entonces, ¿por qué incluso usamos software de base de datos de gran potencia y consultas SQL para   manejar las necesidades bastante limitadas de nombre de usuario y amp; autenticación de contraseña   ¿en absoluto?. ¿Por qué no hay aplicaciones de base de datos de propósito limitado?   específicamente dirigido a hacer lo que una base de datos de contraseñas debe hacer,   vs. usar aplicaciones de propósito general que dejan mucho espacio para SQL   inyección para ocurrir? ¿Qué me estoy perdiendo?

Lo que falta es que las bases de datos son herramientas generales diseñadas para casos de uso generalizados. Lo que estás describiendo es una herramienta muy específica, diseñada para un caso de uso muy específico.

La pregunta se reduce a uno de mantenimiento y costo. En general, es más barato y más fácil de usar herramientas comunes que depender de algo más específico como lo está describiendo.

Si se usa correctamente, una base de datos está perfectamente bien para almacenar datos y consultarlos directamente desde el programa. No conozco personalmente ninguna solución como la que usted describe en un uso generalizado. Eso no significa que no existan, pero implica que no son terriblemente comunes.

Además, todo se reduce al diseño de seguridad. Lo que estás describiendo es un diseño seguro. Si el sitio web en cuestión no fue diseñado pensando en la seguridad, no incluirá características seguras como las que usted describe.

El punto es que la seguridad no (generalmente) simplemente sale de la caja. El valor predeterminado es normalmente sin seguridad. Si no está diseñado y pensado activamente, no lo conseguirás. Ese es uno de los mayores problemas a los que nos enfrentamos, ya que la seguridad debe considerarse desde el principio, no como una idea de último momento.

Agregar más tecnología a la pila no es una forma rentable y muy eficiente de manejar esto, y en general, el almacenamiento de datos de autenticación en la base de datos no es un problema. Es más sobre cómo lo almacena y cómo se puede acceder a él.

Esto nos lleva a su otra pregunta acerca de las inyecciones de SQL. Son fáciles de prevenir, y me atrevo a decir que la mayoría de los sitios que no lo son son el resultado de una programación perezosa y / o un diseño de base de datos perezoso (¡no almacene las contraseñas en texto sin formato!). No quiero decir que eso suene insultante para nadie, pero realmente se reduce al lenguaje o método que se utiliza para llegar a la base de datos y cómo se implementa.

Por ejemplo, PHP solía tener comandos mysql, que luego se convirtieron en mysqli y ahora se recomienda utilizar PDO en situaciones para resolver este problema. La razón por la que se produjo la progresión es para garantizar que cualquier entrada que se proporcione al servidor se presente en un formato válido.

Otra cosa que me llamó la atención aquí es que usted mencionó que las bases de datos están destinadas a devolver información legible por el usuario. Ese es uno de los muchos usos, pero no es exclusivo del propósito de una base de datos. El problema no es la base de datos, es cómo llegas a ella. Hay muchos casos en los que querrás / necesitas poder enviar comandos a una base de datos por razones muy válidas.

Las inyecciones de SQL funcionan en la entrada y si esa entrada se valida o no antes de solicitar información del servidor. Entonces, el problema no es la base de datos, es el proceso de solicitar información de ella. Por supuesto, puede almacenar las credenciales en otros formatos y algunos sí, pero tienden a tener una flexibilidad limitada.

Además, tenga en cuenta que una inyección de SQL es solo uno de los muchos vectores de ataque relacionados. Simplemente recibe mucha prensa porque se trata de la forma más fácil de ingresar a un sistema mal configurado.

Una base de datos no es una herramienta de autenticación. Si ya usó una herramienta de autenticación (el inicio de sesión en el sitio web compartió las credenciales con la computadora o el inicio de sesión de la aplicación en otra parte, por ejemplo, una versión web de la aplicación de finanzas de su empresa), utilice Active Directory, PAM o RADIUS o lo que sea para ambos.

Ejecutar una segunda base de datos aislada, solo para el inicio de sesión del usuario de su aplicación web junto con la base de datos masiva que contiene el resto de sus detalles, además de mantener el intermediario de autenticación, crea más problemas y, en última instancia, esa base de datos aún existe y puede ser violada. muchas otras formas Si cometieran un error al permitir la inyección de SQL, probablemente cometerían otros suficientes errores que expondrían la base de datos "especial" directamente oa través de su procesador de autenticación Homebrew.