Aquí podría ser tu PUBLICIDAD


Captura de inyección SQL y otras solicitudes web maliciosas

votos
17

Estoy buscando una herramienta que pueda detectar solicitudes maliciosas (como obvia inyección de SQL o publicaciones) e inmediatamente prohibirá la dirección IP del solicitante / agregar a una lista negra. Soy consciente de que, en un mundo ideal, nuestro código debería ser capaz de manejar tales solicitudes y tratarlas en consecuencia, pero hay mucho valor en una herramienta de este tipo incluso cuando el sitio está a salvo de este tipo de ataques, ya que puede conducir a ahorrando ancho de banda, evitando la saturación de análisis, etc.

Idealmente, estoy buscando una LAMP/.NETsolución multiplataforma ( ) que se encuentre en un nivel más alto que la pila de tecnología; tal vez en el servidor web o el nivel de hardware. Aunque no estoy seguro de si esto existe.

De cualquier manera, me gustaría escuchar los comentarios de la comunidad para poder ver cuáles podrían ser mis opciones con respecto a la implementación y el enfoque.

Publicado el 04/08/2008 a las 15:40
fuente por usuario Schmidty
En otros idiomas...        العربية       

8 respuestas

votos
10

Si casi lo miras de la manera equivocada, ninguna herramienta 3party que no conozca tus métodos de aplicación / naming / data / domain va a poder protegerte perfectamente.

Algo así como la prevención de inyección SQL es algo que tiene que estar en el código, y mejor escrito por las personas que escribieron el SQL, porque ellos son los que sabrán qué debería / no debería ser en esos campos (a menos que su proyecto tenga muy buenos documentos) )

Tienes razón, todo esto se ha hecho antes. No tiene que reinventar la rueda, pero tiene que tallar una nueva debido a las diferencias en los diámetros de eje de cada uno.

Este no es un problema de lanzamiento y ejecución, realmente tiene que estar familiarizado con exactamente qué es la inyección SQL antes de que pueda evitarla. Es un problema furtivo, por lo que se necesitan protecciones igualmente furtivas.

Estos 2 enlaces me enseñaron mucho más que los conceptos básicos sobre el tema para comenzar, y me ayudaron a expresar mejor mis búsquedas futuras en preguntas específicas que no fueron respondidas.

Y aunque este no es un 100% buscador, le "mostrará la luz" sobre el problema existente en su código actual, pero al igual que con los estándares web, no deje de codificar una vez que pase esta prueba.

Respondida el 04/08/2008 a las 04:43
fuente por usuario Uberfuzzy


Aquí podría ser tu PUBLICIDAD


votos
5

El problema con una herramienta genérica es que es muy difícil crear un conjunto de reglas que solo coincidan con un ataque genuino.

Las palabras clave SQL son todas palabras en inglés, y no olvide que la cadena

 DROP TABLE users;

es perfectamente válido en un campo de formulario que, por ejemplo, contiene una respuesta a una pregunta de programación.

La única opción sensata es desinfectar la entrada antes de pasarla a su base de datos, pero pasarla de todos modos. De lo contrario, muchos usuarios perfectamente normales y no maliciosos serán expulsados ​​de su sitio.

Respondida el 04/08/2008 a las 04:11
fuente por usuario Mat

votos
3

Oracle tiene un tutorial en línea sobre inyección de SQL . A pesar de que desea una solución ya hecha, esto podría darle algunos consejos sobre cómo usarla mejor para defenderse.

Respondida el 05/08/2008 a las 06:38
fuente por usuario Mario Marinato

votos
3

Una cosa a tener en cuenta: en algunos países (es decir, la mayor parte de Europa), las personas no tienen direcciones IP estáticas, por lo que la lista negra no debería ser para siempre.

Respondida el 04/08/2008 a las 04:22
fuente por usuario Michael Stum

votos
3

Un método que podría funcionar en algunos casos sería tomar la cadena sql que se ejecutaría si ingenuamente utilizara los datos del formulario y los pasara a algún código que cuente el número de sentencias que realmente se ejecutarían. Si es mayor que la cantidad esperada, existe una probabilidad decente de que se haya intentado inyectar, especialmente para campos que probablemente no incluyan caracteres de control como el nombre de usuario.

Algo como un cuadro de texto normal sería un poco más difícil ya que este método sería mucho más probable que arrojara falsos positivos, pero esto sería un comienzo, al menos.

Respondida el 04/08/2008 a las 04:20
fuente por usuario ricree

votos
0

Interesante cómo se está llevando a cabo años más tarde por Google y les eliminación de la URL todos juntos con el fin de prevenir ataques XSS y otras acitivites maliciosos

Respondida el 24/07/2014 a las 06:18
fuente por usuario ECE

votos
0

Uno de mis sitios fue pirateado recientemente a través de SQL Injection. ¡Agregó un enlace a un virus para cada campo de texto en el db! La solución fue agregar un código buscando palabras clave SQL. Afortunadamente, he desarrollado en ColdFiusion, por lo que el código se encuentra en mi archivo Application.cfm que se ejecuta al comienzo de cada página web y analiza todas las variables de URL. Wikipedia tiene algunos buenos enlaces para ayudar también.

Respondida el 16/09/2008 a las 03:04
fuente por usuario user7428

votos
0

Ahora que lo pienso, un filtro bayesiano similar a los utilizados para bloquear el correo no deseado también podría funcionar decentemente. Si reuniste un conjunto de texto normal para cada campo y un conjunto de inyecciones sql, es posible que puedas entrenarlo para marcar ataques de inyección.

Respondida el 04/08/2008 a las 04:26
fuente por usuario ricree