¿Cómo puedo asegurar mi sitio de las inyecciones Havij SQL?

No necesita técnicas especiales, herramientas, marcos o cortafuegos para defenderse de Havij. Cualquiera que te diga algo diferente está vendiendo algo.

Havij no puede explotar una página web que ya no es vulnerable a la inyección SQL ordinaria: Havij lo hace más rápido y ayuda a los niños de script a perpetrar intrusiones.

Las defensas contra Havij y herramientas similares son las mismas defensas contra cualquier ataque de inyección SQL:

  • Filtre contenido no confiable para quitarle cualquier carácter inesperado. Por ejemplo, si espera un número entero, coaccione la entrada a un número entero eliminando cualquier carácter después de los dígitos numéricos iniciales.
  • Escape del contenido dinámico antes de interpolarlo en expresiones SQL. Básicamente, esto significa usar una función para asegurarse de que los caracteres de comillas literales en la entrada no sirvan como un terminador de cadena al interpolar.
  • Mejor aún, use parámetros de consulta SQL para valores dinámicos. Esto significa que no necesita hacer ningún escape, porque un parámetro siempre se interpreta como un valor constante único. Los parámetros nunca pueden causar inyección SQL. Tenga en cuenta que algunas bibliotecas de bases de datos “simulan” parámetros, pero en realidad están interpolando.
  • Incluya en la lista blanca cadenas legítimas y descarte todo lo que no esté en la lista blanca. Esta es una buena manera de protegerse contra la inyección cuando el contenido dinámico no se puede escapar o parametrizar. Por ejemplo, nombres de tablas, nombres de columnas, palabras clave SQL, expresiones SQL.

La mejor manera de implementar estas defensas es mediante la revisión del código en su aplicación, y para cada caso de SQL dinámico, asegúrese de saber dónde se originaron todas las entradas y si se han desinfectado fielmente.

También puede leer mi presentación Mitos y falacias de la inyección SQL.

bueno, me pregunto por qué la gente ve estas herramientas solo desde el punto de vista del vector de ataque. herramientas como havij, sqlmap también se pueden usar para detectar ataques de inyección sql. Según el punto de vista de un hacker, las formas de proteger sus sitios contra sqli:
1. codificación web segura.
2. Como otras medidas de seguridad han sido enumeradas por lgal, la única medida que no se discute aquí es el diseño del sistema de detección y prevención de intrusos. Se puede implementar de dos maneras:
1. la entrada obtenida de un formulario HTML se compara con los patrones de ataque SQL-I conocidos (o firmas). Si se encuentra que la entrada coincide con una firma, se deniega el acceso y el usuario recibe una pantalla genérica de nombre de usuario / contraseña no válida. Intencionalmente evitamos devolver una página con una respuesta HTTP o un código de estado que describirá el error que ocurrió al usuario. Esto es para limitar la información y los comentarios que el sistema IDPS da a los posibles intrusos. Incluso la información que parece perfectamente inofensiva puede dar pistas sobre cómo funciona nuestro sistema a los atacantes, lo que puede ayudarlos a encontrar una manera de eludir las protecciones del sistema. Si un usuario envía una entrada que coincide con una firma conocida un número arbitrario de veces, la IP del usuario se bloquea automáticamente para acceder por completo al sistema. Un administrador tendría que desbloquear la IP para que este usuario recupere el acceso.
pero, las firmas en sí mismas tendrían que ser eficientes, porque una base de datos que contiene demasiadas firmas o firmas escritas de manera ineficiente daría como resultado un bajo rendimiento. Además, las firmas tendrían que elegirse con cuidado, ya que nos gustaría minimizar la cantidad de falsos positivos devueltos. La mayor falla en el modelo de detección basado en firmas es que no puede detectar ataques que son desconocidos. Esa es la razón por la cual el IDPS se basa en el modelo de detección basado en anomalías como complemento del modelo de detección basado en firmas.
2. ya que el atacante intentará diferentes combinaciones mientras realiza el ataque. por lo tanto, se considera la cantidad de veces que un usuario intenta iniciar sesión en el sistema, exitoso o no. Si los intentos de un usuario exceden un número predeterminado, el sistema bloqueará la IP de este usuario por un período de tiempo. El usuario puede volver a intentarlo una vez transcurrido este tiempo. Es importante que este período y umbral sean arbitrarios. Esto le permite al administrador del sistema determinar cuáles son los valores apropiados para cada aplicación en particular, ya que los diferentes sistemas tienen diferentes requisitos. Cada vez que el sistema detecta un posible ataque, registra un ataque y puede impedir que un atacante acceda más al sistema. . Además, se puede enviar una alerta al administrador del sistema.