java - prevent - Código malo: ¿Por qué es esto peligroso?

sql injection recommendation

Question

Posible duplicado:
¿Puedo protegerme contra la inyección de SQL escapando la comilla simple y la entrada del usuario circundante con comillas simples?

 String badInput = rawInput.replace("''","''''");
ResultSet rs = statement.executeQuery("SELECT * FROM records WHERE col1 = ''"+badInput+"''";

¿Hay alguna manera de hacer un ataque tipo " Bobby Tables " en este código?

Answer 1

Dependiendo de los diferentes pasos a lo largo del camino que todos tienen que interpretar el comando, puede haber alguna posibilidad de pasar %27 (por ejemplo) y hacer que actúe como una única cotización, pasando desapercibido a través de su reemplazo.

Pero incluso si todos esos casos pudieran ser cubiertos, y en realidad era seguro para esta sola pregunta, falta que no se pueda implementar de manera uniforme. Puede que alguien más AND int1 = var1 y quiera agregar AND int1 = var1 , y AND int1 = var1 que ha pensado en la inyección de SQL, por lo que simplemente modifican el código de la manera exacta en que lo tiene.

String badInput = rawInput.replace("''","''''");
String badInteger = rawInteger.replace("''","''''");
ResultSet rs = statement.executeQuery("SELECT * FROM records WHERE" +
"int1 = " + badInteger + " OR col1 = ''"+badInput+"''");

... solo con números enteros, ¡ya no se trata de citas de las que quieras protegerte! Aquí, es fácil ver que algo podría salir mal. Entonces, aunque ese es un problema que requiere que alguien lo implemente mal, creo que es el mayor problema del diseño, solo cubre un conjunto limitado de casos.

Siempre será mejor poder decir "lo siguiente es una variable. Lo que sea que contenga, trátalo como un valor, y no intentes usar partes de él como código y ejecuta ese código".

Answer 2

En MySQL, si la opción NO_BACKSLASH_ESCAPES no está configurada, creo que es posible hacerlo.

/'); DROP 

O algo similar. Tu código duplicará el '' . El primero '' será escapado por la barra diagonal inversa y el segundo cerrará la cadena permitiendo la inyección de SQL.

Por lo general, prefiero atenerme a las declaraciones preparadas para estar seguro.

Answer 3

Eso es propenso y siempre invita a un ataque de inyección.

Answer 4

No soy un experto en seguridad, pero ¿no char() efectivamente char() sus medidas de seguridad?

Ejemplo: obtener todo de la tabla de registros

SELECT * FROM records WHERE col1 = char(39,97,39)

Ejemplo 2: escribir información en archivos sin comillas simples

SELECT * FROM records WHERE col1 = concat(char(39),char(97),char(100),char(109),char(105),char(110),char( 39)) into outfile concat(char(39),char(97),char(100),char(109),char(105),char(110),char( 39))

Fuente aquí: Hoja de trucos SQL Injection

Answer 5

Porque solo tiene que haber un pirata informático que invente una forma de eludir los reemplazos de una manera que no podemos pensar hoy. (¿Un pequeño error en una de las capas para acceder a la base de datos?)

Answer 6

Puede intentar:

badInput = "//'; drop records; --";

en caso de que su personaje de escape se establezca en ''/' .

Answer 7

Recientemente presenté a mi hermano a la declaración de preparación. Después de haberlo implementado en su proyecto actual, encontró

• Él podría deshacerse de todo el escape desordenado
• él podría deshacerse de toda la concatenación de cadenas desordenadas
• Su código corrió más rápido.

¿Por qué alguien no usaría prepararse?

Answer 8

Tal vez. Depende de lo que ese método de replace realmente hace, especialmente cuando encuentra pares de sustitución unicode o marcas de combinación, y de manera similar cómo la tecnología de acceso a la base de datos maneja dichos pares. Si el replace funciona a nivel char, si un atacante te proporciona un sustituto alto válido seguido de un carácter de comillas simples, puedes sustituir esa comilla simple con un par de comillas simples, en efecto, añadiendo una comilla simple después algo que, probablemente, pase a través de una codificación y se interprete como un par sustituto no válido, dejando un carácter de comillas simples desnudas.

Tal vez.

¿Sabe lo suficiente acerca de las características Unicode de ese método de reemplazo y cada biblioteca de manejo de cadena entre su código y el motor de ejecución de SQL en el otro extremo de la conexión DB?

¿Te sientes afortunado?

Use una consulta parametrizada.