De las revelaciones públicas que he visto en sitios recientemente comprometidos, parece común que solo se filtre la base de datos, en lugar del código de la aplicación, o en lugar de una toma de control completa. ¿Esto se debe a que hay una clase de ataques comunes que están limitados al acceso a bases de datos de solo lectura?
Los primeros pocos que vienen a la mente son:
También es completamente posible que los atacantes en las filtraciones de las que hablabas tuvieran privilegios completos o al menos más privilegios que solo de solo lectura, pero optaron por no usarlos. O los usaron pero ese uso aún no se ha detectado. O que tengan el código completo de la aplicación, pero decidieron no filtrarlo.
Un pensamiento interesante que acabo de tener al escribir esto sobre la prevención 1. al reducir la superficie de ataque es tener una cuenta de usuario de base de datos separada que solo tenga acceso a la tabla de credenciales y su usuario normal de solo lectura no tenga acceso a esta mesa De esa manera, solo una inyección de SQL en el formulario de inicio de sesión puede comprometer sus hashes de contraseña. Cualquier inyección de SQL en otra parte de la aplicación web no puede ver los hashes de contraseña (o cualquier otra información confidencial que tenga).
La base de datos es la mina de oro, por eso filtrar los datos significa todas las cosas malas. El código fuente de la aplicación es importante en algunos casos, pero si observa la arquitectura de las aplicaciones modernas, la mayoría de los datos provienen de la base de datos back-end. Credenciales, PII, números de tarjetas de crédito, datos financieros y comerciales, casi todo lo que desea proteger está en la base de datos.
Comprometer al servidor (como obtener el shell) solo importa en caso de ataques de bot para que la red de bot se expanda. Los ataques dirigidos son siempre para los datos. Por lo tanto, comprometer la base de datos significa lograr el objetivo.
En lo que respecta a sus "ataques de comando", la mayoría de los sitios web están comprometidos a través de la inyección de SQL que ejecuta directamente las consultas de los atacantes en la base de datos. La base de datos de solo lectura es lo mínimo que se obtiene en la inyección de SQL. SQLi también puede comprometer totalmente la máquina al cargar el código de shell a través de la directiva "INTO DUMPFILE" y estos llaman al shell a través de la aplicación web, lo que da como resultado un shell interactivo completo a través del navegador.
Por lo tanto, la pérdida de datos la mayoría de las veces alcanza el objetivo, por eso los atacantes se detienen allí. De lo contrario, la inyección de SQL también ofrece muchas otras vías de ataque.
Supongo que si encuentran una inyección SQL y el usuario que usa el sitio web para consultar la base de datos solo tiene acceso de lectura, el resultado sería que solo puede hacer un ataque de inyección de SQL de solo lectura. Pero no creo que exista una clase específica para ese tipo de ataques. En general, solo añadimos nombre del ataque
Si la base de datos es la única parte comprometida de la aplicación web, es casi siempre una Inyección SQL , que abusa de una función de la aplicación (por ejemplo, un formulario de búsqueda) para extraer datos arbitrarios del subyacente base de datos.
Una pérdida en la base de datos también podría ser causada por un ataque interno , realizado por un empleado que tenía suficientes privilegios para acceder a la base de datos.
También se pueden encontrar volcados de bases de datos parciales y completos a través de Google Hacking , que utiliza motores de búsqueda para descubrir archivos confidenciales que se indexaron.
Por último, incluiría errores de aplicación que podrían revelar datos de la base de datos si las excepciones no se manejan correctamente.