Il codice SQL nativo può essere vulnerabile? A cosa?

2

Sono stato in grado di trovare un articolo indica che l'iniezione SQL può essere eseguita su codice SQL nei seguenti scenari in cui sono coinvolte le stored procedure:

  • istruzioni EXEC
  • Cursori dinamici

Supponendo che SQLi non sia direttamente possibile (abbiamo preparato dichiarazioni e input di risanamento ovunque venga preso l'input dell'utente) ma un utente malintenzionato può ottenere informazioni nel database e il codice SQL elabora queste informazioni (ad esempio, tramite una query a una tabella contenente il input di attacker), ci sono altri tipi di codice SQL di cui dovremmo preoccuparci?

    
posta Daniel V 15.03.2018 - 18:41
fonte

1 risposta

2

In questo caso, XSS persistente (memorizzato) non ha nulla a che fare con il rischio effettivo di SQL Injection (SQLi). XSS memorizzato è un vettore di attacco ma non richiesto per SQLi. Le due regole d'oro della protezione contro SQLi sono:

  • Disinstalla tutti input fornito dall'utente (inclusi gli URI)
  • Utilizza query parametrizzate anziché concatenare SQL raw

Convalidare sempre il tuo sito dopo eventuali aggiornamenti del codice per garantire che le aspettative (ipotesi) siano ancora valide. Se stai cercando di determinare l'impatto, considera la seguente fonte per informazioni aggiuntive su SQLi .

EDIT Aggiornato per riflettere la domanda aggiornata

Supponendo che tu stia chiedendo se il codice dannoso, memorizzato come dati nel database, possa essere dannoso per il richiamo di query, processi, ecc. la risposta è: dipende. In genere, il codice dannoso non sarebbe la sintassi SQL ma HTML / JS. Per questo motivo, è ugualmente (e talvolta più) importante eseguire la sanitizzazione dell'output per ridurre il rischio per l'entità che consuma (db, webserver, user, ecc.).

    
risposta data 15.03.2018 - 18:49
fonte

Leggi altre domande sui tag