Detectar conjuntos de datos que fueron afectados por la inyección de SQL

Question

Detectar conjuntos de datos que fueron afectados por la inyección de SQL

#1 de NSSec (1 votos)

0

Suponiendo que sé que una de mis aplicaciones fue atacada por una inyección de SQL, ¿cómo puedo identificar los conjuntos de datos editados o seleccionados?

En la fuente obvia están los registros del servidor web. Esto debería permitirnos identificar la vulnerabilidad y el código inyectado. Por lo general, el servidor web solo registra las solicitudes GET pero no las solicitudes POST. Esto limita el uso de los registros del servidor web.

Sé que MySQL y otros DBMS tienen diferentes tipos de archivos de registro, por ejemplo. para consultas lentas. ¿Hay otros lugares que puedan ayudar en este caso? ¿Hay alguna configuración o ajuste que deba aplicar de antemano y que simplifique el análisis?

sql-injection forensics sql-server mysql

pregunta Stefan Braun 20.05.2016 - 21:58

fuente

1 respuesta

Lea otras preguntas en las etiquetas sql-injection forensics sql-server mysql

¿Por qué es malo almacenar los nombres de usuario en las cookies? [duplicar] ¿Es posible usar CSP para un reproductor de video basado en Javascript?

score 1 · Answer 1

Si ya experimentó un ataque de inyección de SQL:

MySQL por defecto no registra todas las consultas [1], ya que afectaría significativamente el rendimiento. Tampoco es suficiente simplemente considerar las tablas a las que se accede directamente a su aplicación web.

Si no tiene habilitado el registro o la auditoría, determine qué tablas se considerarían de "alto valor" en la base de datos principal. Piense: users , user_creditcards , oauth_keys . Cualquier cosa que pueda generar una ganancia (ganancia financiera, mayor acceso, contraseñas) para su atacante. Esos son probablemente comprometidos.
También considere cualquier otra base de datos a la que tenga acceso el usuario utilizado por la aplicación web.
¿Usar replicación? [2] Encuentre el período de tiempo de ataque en los registros de acceso e inspeccione los MySQL Binlogs disponibles para ese momento. Esto solo le dará consultas de modificación ( UPDATE/INSERT/DELETE/CREATE/ALTER/DROP ).
¿Su red está monitoreada? ¿Está la base de datos en un host diferente y la conexión no está encriptada? Pregunte a los tipos de seguridad de la red si tienen alguna captura del tráfico de la red. Investiga las capturas con Wireshark [3].
Determine si LOAD DATA INFILE / INTO OUTFILE [4] estaba disponible para el usuario de la base de datos. Si es así, también debe investigar más a fondo el servidor que aloja la base de datos para obtener más señales de compromiso.

Si está intentando diseñar un procedimiento de respuesta a incidentes / tácticas de defensa o pautas de configuración:

Considere usar un complemento de auditoría [5]. Determine sus tablas de alto valor. Auditar el acceso a esas tablas por parte de los usuarios relevantes. El registro resultante puede contener consultas altamente sensibles, proteger en consecuencia. Implementar la política de retención.
Considere implementar un WAF para al menos capturar indicaciones de ataques. Vea si puede marcar una IP como sospechosa y registrar todo su tráfico durante un período. De nuevo, esto genera datos sensibles. Proteger en consecuencia.
Limite el usuario de la base de datos en la aplicación web al mínimo absoluto al que debería poder acceder. Esto también significa ver si puede limitar los patrones de acceso para el usuario de la base de datos: ¿tiene que ser capaz de SELECT * FROM secrets o tendría sentido limitar este usuario de la aplicación a un procedimiento almacenado ala CALL findSecretByIdentifier('MySecretIdentifier'); ?

Recursos:

[1] enlace

[2] enlace

[3] enlace

[4] enlace

[5] enlace