impidiendo la inyección de SQL con la longitud de la cadena [duplicado]

Question

impidiendo la inyección de SQL con la longitud de la cadena [duplicado]

#1 de pri (1 votos)
#2 de pm1391 (-1 votos)

3

Esto dista mucho de ser una buena práctica, pero acabo de ver un fragmento de código que me pareció muy interesante, como mínimo. El código estaba ejecutando algo de SQL y no estaba usando declaraciones preparadas, por lo que está completamente abierto para la inyección de SQL.

Sin embargo, tenía un enfoque poco ortodoxo para esto. Es "seguro" porque todos los parámetros de entrada están limitados a 2 caracteres. Y esto me hizo pensar: ¿hay alguna forma en que un atacante pueda explotar esto? Por supuesto, cambiaré el código para usar declaraciones preparadas, pero aún así, estoy bastante curioso

sql-injection databases

pregunta munHunger 22.03.2018 - 11:39

fuente

2 respuestas

Lea otras preguntas en las etiquetas sql-injection databases

¿El número de cuenta bancaria y el titular de la cuenta en cheque expuesto? ¿Cuál es el enfoque general para crear SSH compatible con FIPS?

score 1 · Answer 1

Reduce la posibilidad / magnitud del daño causado por la inyección de SQL, pero definitivamente NO protege su aplicación contra ella.

Por ejemplo, digamos que su campo toma una entrada de 2 caracteres, y el servidor ejecuta una operación LIKE en la entrada. Supongamos que el usuario ingresa algo como A* , que satisface el límite de 2 caracteres, pero esto resultaría en todos los registros que comienzan con el carácter A , y dependiendo del escenario, el usuario podría tener acceso a datos que no se supone. a.

Por lo tanto, la validación de entrada siempre debe realizarse inmediatamente después de aceptar la entrada, así como antes de enviarla al usuario.

score -1 · Answer 2

Hay toneladas de recursos disponibles sobre las mejores prácticas para tomar parámetros de entrada y nunca he visto solo limitar la longitud del carácter como una opción viable o segura. Así que sí, un atacante puede explotar esto. Después de todo, ya está abierto a la inyección de SQL, por lo que no puede estar seguro de los posibles ataques y limitar la duración seguramente no le ayuda a dormir. Generalmente, si no está utilizando declaraciones preparadas, tiene una lista blanca de entradas o un criterio específico de las entradas que acepta. Si la entrada suministrada no coincide, se produce un error. La verificación de la longitud de una entrada está bien, pero no debería ser la única defensa sino una restricción adicional en su aplicación.

Por ejemplo, un atacante podría usar " or ""=" como un posible ataque de inyección. Si bien este es más largo que 2 caracteres, puedes ver que hay muchas maneras diferentes de hacerlo y estoy seguro de que algunos son 2 caracteres.