¿Cómo debo detectar y responder a los actores malos que realizan inyecciones de SQL?

Question

¿Cómo debo detectar y responder a los actores malos que realizan inyecciones de SQL?

#1 de Aria (1 votos)

0

SQL Azure tiene un componente lógico llamado Detección de amenazas . Supongo que busca Inyección SQL, pero también evidencia de comandos peligrosos como sp_exec.

Me gustaría expandir ese alcance y también inspeccionar los siguientes aspectos del tráfico de usuarios para la inyección de SQL, y otros tipos de comportamiento de piratería ...

HTTP GET / POST (u otros verbos)
Encabezados de clientes (que se mostrarían en las soluciones de administración de registros)
Cookies no enviadas por mi sitio

Suponiendo que algo arriba active una alerta, ¿cuál es la respuesta más apropiada?

Bloquea la dirección IP
Reautentica al usuario
Bloquear la cuenta
¿Marcar la sesión?

¿Qué clase de herramientas de seguridad serían apropiadas para este tipo de actividad (en la nube) y dónde puedo obtener más información sobre formas inteligentes de manejar las diferentes respuestas / técnicas de mitigación?

sql-injection incident-response threat-mitigation cloud-computing azure

pregunta random65537 06.08.2016 - 15:55

fuente

1 respuesta

Lea otras preguntas en las etiquetas sql-injection incident-response threat-mitigation cloud-computing azure

¿Cómo se explotan los conjuntos de cifrado anónimo? Robots que intentan iniciar sesión en Azure VM cuando el puerto SSH está cerrado en el administrador

score 1 · Answer 1

La forma correcta de actuar es rechazar la solicitud (fallar la solicitud antes de iniciar cualquier código de aplicación / consultas SQL) y registrar el evento con información completa de depuración en la base de datos, asignarle un número y enviar el número a la pantalla.

Esta no debe ser la misma base de datos que la operativa, debe ser una base de datos de servicio donde normalmente almacena registros de operaciones.

Si es una llamada a la API, haga que este número aparezca en el cuadro de mensaje de error. Se trata de lidiar con falsos positivos por una vez y, en segundo lugar, con los intentos exitosos de inyecciones.

Sin embargo, no puedes evitar "seleccionar 1;" los argumentos se pasan cada vez porque siempre es posible pasar "select 1;" en algún lugar y dicha solicitud debe bloquearse antes de llegar al código de la aplicación. Además, esto se implementa mejor en una "capa" dedicada donde la solicitud se decodifica y se verifica para este tipo de cosas como mod_security .

No hay manera de bloquear al usuario y cerrar sesión porque habrá un impacto demasiado grande, también está en la capa incorrecta: es la capa de código de la aplicación y no la capa de seguridad dedicada.