¿Se pueden evitar 4 comillas simples produciendo una inyección de SQL en el servidor de SQL? [duplicar]

Question

¿Se pueden evitar 4 comillas simples produciendo una inyección de SQL en el servidor de SQL? [duplicar]

#1 de Luc (1 votos)
#2 de Egret (0 votos)

4

Encontré una ruptura simple en una cláusula where en uno de nuestros proyectos donde el código es tan antiguo que dicen que no pueden usar parámetros para comunicarse con ms SQL Server. Está escrito en C ++, no puedo leer este idioma y no puedo acceder al código de ninguna manera.

Para ilustrar el problema, agregué un ejemplo de una declaración no dañina, la parte en negrita es lo que el usuario puede ingresar directamente

SELECCIONAR '1 'SELECCIONA 2-- ';

La comilla simple después de 1 está causando la ruptura en este escenario. Esto es lo que he mostrado al equipo.

Luego hicieron una detección en el código que busca comillas simples y agregan otras tres comillas simples después de cada cita que encuentran. Así el ejemplo se convertiría en este

.

SELECCIONA '1' '' 'SELECCIONA 2-- ';

No me gusta esta solución en absoluto, pero no puedo encontrar una manera de salir más. Los campos dentro de la base de datos se almacenan tratados como nvarchar caracteres. ¿Existe todavía la posibilidad de evitar esta práctica en cualquier tipo?

sql-injection c++ sql-server

pregunta Samyne 07.02.2018 - 10:51

fuente

2 respuestas

Lea otras preguntas en las etiquetas sql-injection c++ sql-server

Reduciendo el riesgo de exposición a malware de dispositivos de almacenamiento USB ¿Cuál es el impacto / pérdida de rendimiento esperado de los parches de fusión / espectro? [duplicar]

score 1 · Answer 1

el código es tan antiguo que dicen que no pueden usar parámetros para comunicarse con ms SQL server

Esa es una pésima excusa. Es como decir "su auto es tan viejo, no podemos usar cinturones de seguridad". Es posible que tengan que rehacer mucho trabajo con técnicas más modernas, pero se puede hacer.

La solución que aplicaron está escapando, que es una solución correcta (la segunda mejor para consultas parametrizadas) Para escapar de un apóstrofe (o 'comilla simple') en MSSQL, puede prefijo con otro apóstrofe . ¿Por qué los desarrolladores agregaron dos más? La única explicación que se me ocurre es que la salida se interpreta como SQL nuevamente, pero honestamente no lo sé y debería crear errores, si no otra cosa.

En cuanto a cómo salir de eso, esa parte de su pregunta parece ser un duplicado de esta (aunque la suya es específica para MSSQL):

Cómo derrotar el doblar los apostrofes para crear un ataque SQLi?

La respuesta es básicamente:

[...] puede forzar a varias bases de datos SQL a traducir Unicode al conjunto de caracteres local . Por ejemplo, Ā podría convertirse a A . Peor aún: U+02BC , o ʼ se traduciría como ' , que es U+0027 . Esto se llama Contrabando basado en Unicode .

score 0 · Answer 2

Están codificando los caracteres peligrosos. Este no es un mal enfoque, pero puede crear otros problemas. Están cambiando la longitud de la cadena: si no están teniendo cuidado de verificar la longitud después de la codificación, podrían abrirse a un desbordamiento del búfer o (en algunos casos) truncar la codificación en el medio para crear cita inesperada.

Pruebe una entrada de todas las comillas simples y vea qué sucede.

Es mejor rechazar las comillas simples, asumiendo que este es un nombre de columna y puede estar seguro de que no hay columnas con comillas simples.