È possibile l'iniezione SQL nella concatenazione di stringhe quando tutte le variabili sono create dal programma

Question

È possibile l'iniezione SQL nella concatenazione di stringhe quando tutte le variabili sono create dal programma

#1 da (1 voti)
#2 da (0 voti)

1

Dire che ho un programma che restituisce alcune stringhe di data da una funzione in 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];
}

Quindi, dì che ottengo questi valori e li inserisco in una dichiarazione SQL.

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

Questa query SQL è in qualche modo vulnerabile? Supponi che un utente chiami la funzione calledByUserViaWebAPI .

javascript sql-injection

posta jaredad7 01.10.2018 - 21:33

fonte

2 risposte

0

L'iniezione richiede i dati che un utente malintenzionato può controllare: per il tuo esempio presumo che si tratti di un'impostazione client-server con il codice in esecuzione sul server.

Non è iniettabile a meno che il processo delle funzioni non stia usando qualcosa che l'utente fornisce direttamente o indirettamente (diciamo stringa di cultura o qualcosa del genere).

Il tuo esempio ha l'input completamente controllato dall'applicazione e dall'host (supponendo che le informazioni dei dati provengano dall'host) quindi non c'è alcun vettore per l'iniezione o la manomissione, a meno che qualcuno non modifichi la data dell'host.

Sì SAST lo rileverà come un problema, ma SAST è buono solo come le regole scritte e la maggior parte delle regole SAST è molto semplice & limitato, non la sera ispezionando al di fuori di un ambito di funzione. Queste regole non avranno l'intelligenza di ispezionare dove arrivano i dati.

risposta data 01.10.2018 - 23:04

fonte

Leggi altre domande sui tag javascript sql-injection

Ci sono attualmente standard per la crittografia omomorfica? Servizio SMTP STARTTLS Iniezione comando testo normale

score 1 · Accepted Answer

È attualmente vulnerabile? No .

Dovresti cambiarlo comunque? Probabilmente

Se stai inserendo variabili in una query SQL, dovresti utilizzare le query preparate. Non hanno praticamente alcun impatto sulla tua base di codice e di solito hanno solo un piccolo impatto sulle prestazioni. Di conseguenza, il costo dell'utilizzo di query preparate è ridotto. Ovviamente mi chiederesti "Ma non c'è vulnerabilità qui, quindi perché dovrei prendermi il tempo di cambiarla?". La risposta è semplice: non sai mai come cambierà il tuo codice più tardi

Cosa succede se la direzione della strada decide di lasciare che gli utenti selezionino l'intervallo di date da soli? Un programmatore affrettato aggiorna il metodo getDates per restituire l'input dall'utente e non esegue alcuna convalida su di esso (il programmatore è di fretta, dopotutto, e non pensa di controllare ovunque e vedere come viene usato il valore di ritorno).

Ora hai una vulnerabilità SQL. Può sembrare un allungamento, ma molte debolezze di sicurezza si verificano a seguito di piccole modifiche incrementali del codice in cui qualcuno che arriva in seguito non ricorda più il contesto completo del codice in questione. Di conseguenza, la mia regola generale è che fino a quando la query preparata è facile da inserire con problemi di prestazioni minimi, quindi utilizzare query preparate per le variabili anche se (al momento) sembra non necessario.

Inoltre, penso che sia meglio avere l'abitudine di usare le query preparate e saltarle solo dopo un'attenta considerazione, piuttosto che abituarsi a saltare le query preparate e solo usando dopo averle attentamente considerazione. L'abitudine successiva genererà molti più problemi di sicurezza.