¿Es posible la inyección SQL en la concatenación de cadenas cuando el programa crea todas las variables?

Question

¿Es posible la inyección SQL en la concatenación de cadenas cuando el programa crea todas las variables?

#1 de Conor Mancone (1 votos)
#2 de McMatty (0 votos)

1

Supongamos que tengo un programa que devuelve algunas cadenas de fecha de una función en javascript.

function getDates()
{
    var yesterday = [some code that gets current time with yesterday's date];
    var today = [some code that gets today's time and date];
    return [yesterday.toSomeDBStorageStringFormat, today.toSomeDBStorageStringFormat];
}

Luego, diga que obtengo estos valores y los conecto a una declaración SQL.

function calledByUserViaWebAPI()
{
    var dates = getDates();
    var response = queryDB('SELECT * FROM Table T WHERE T.Date BETWEEN ' + dates[0] + ' AND ' + dates[1] + ';');
    return response;
}

¿Es esta consulta de SQL de alguna manera vulnerable? Digamos que un usuario llama a la función calledByUserViaWebAPI .

sql-injection javascript

pregunta jaredad7 01.10.2018 - 21:33

fuente

2 respuestas

0

La inyección requiere datos que un atacante puede controlar; para su ejemplo, asumo que esta es una configuración cliente-servidor con el código que se ejecuta en el servidor.

No es inyectable a menos que el proceso de las funciones esté usando algo que el usuario proporciona directa o indirectamente (digamos cadena de cultura o algo así).

Su ejemplo tiene que la entrada está completamente controlada por la aplicación y el host (suponiendo que la información de los datos proviene del host), por lo que no hay un vector para inyección o manipulación, a menos que alguien cambie la fecha del host.

Sí, SAST detectará esto como un problema, pero SAST solo es tan bueno como las reglas escritas y la mayoría de las reglas de SAST son muy simples y amp; Inspección limitada, no por la noche fuera del alcance de una función. Esas reglas no tendrán la inteligencia necesaria para inspeccionar el lugar donde se envían los datos.

respondido por el McMatty 01.10.2018 - 23:04

fuente

Lea otras preguntas en las etiquetas sql-injection javascript

Claves simétricas para un TPM [duplicado] Contraseñas: almacenar encriptadas, ver en texto sin formato

score 1 · Accepted Answer

¿Es actualmente vulnerable? No .

¿Deberías cambiarlo de todos modos? Probablemente

Si está colocando variables en una consulta SQL, debería usar consultas preparadas. Casi no tienen impacto en su base de código y, por lo general, solo tienen un impacto mínimo en el rendimiento. Como resultado, el costo de utilizar consultas preparadas es pequeño. Obviamente, usted preguntaría "Pero aquí no hay vulnerabilidad, ¿por qué debería tomarme el tiempo para cambiarla?". La respuesta es simple: nunca sabes cómo cambiará tu código más adelante

¿Qué sucede si la administración en el camino decide que quieren permitir que los usuarios seleccionen ellos mismos el intervalo de fechas? Un programador apresurado actualiza el método getDates para devolver la entrada del usuario y no realiza ninguna validación en él (después de todo, el programador tiene prisa y no piensa revisar en todas partes y ver cómo se usa el valor de retorno).

Ahora tienes una vulnerabilidad de SQL. Puede parecer un tramo, pero muchas debilidades de seguridad ocurren como resultado de pequeños cambios de código incrementales en los que alguien que llega más tarde ya no recuerda el contexto completo del código en cuestión. Como resultado, mi regla de oro es que siempre que la consulta preparada sea fácil de colocar con problemas de rendimiento mínimos, utilice las consultas preparadas para sus variables incluso si (actualmente) parece innecesario.

Además, creo que es mejor tener el hábito de usar consultas preparadas y solo omitirlas luego de una cuidadosa consideración, en lugar de tener la costumbre de omitir consultas preparadas y solo usarlas después de cuidadosas consideración. El hábito posterior generará muchos más problemas de seguridad.