Il mio fornitore è vulnerabile all'iniezione SQL?

Non ho lavorato con i sistemi di buste paga e non so quanti anni hai. So che spesso devono supportare formati di dati antichi, quindi potrebbe essere necessario farlo per compatibilità. Anche così, questo è indicativo di un sistema imperfetto e di una società che non ha le risorse per riparare il proprio software. Non segue immediatamente che è vulnerabile all'iniezione SQL. Vale la pena provarlo, però.

È scritto nei contratti stipulati con i fornitori che consentono una valutazione della sicurezza, se vogliamo.

Il mio consiglio è di chiedere la documentazione delle loro valutazioni di sicurezza e, se non sei soddisfatto, di 'loro che devi fare la tua valutazione di sicurezza. A meno che non abbiano assunto una società esterna e abbiano un rapporto completo (più lungo di una pagina, per esempio), e possano mostrare una cronologia di valutazioni e miglioramenti, probabilmente non dovresti essere soddisfatto. Quindi puoi assumere qualcuno per farlo o farlo da solo se ti senti a tuo agio nel farlo.

Non significa necessariamente che siano vulnerabili. Potrebbero averlo rimosso solo per paranoia.

Tuttavia , nel mio libro è una cattiva pratica farlo. Stai cambiando il nome , non è come un identificatore in cui una restrizione dei caratteri non conterebbe troppo e non significa nemmeno che tu sia al sicuro.

Inoltre, il fatto che sia stato rimosso il giorno dopo averlo modificato suggerisce che non si tratta di un filtraggio fatto su input, ma di un processo notturno vulnerabile che si è rotto a causa del "e qualcuno poi lo ha rimosso.

Sono d'accordo che vale la pena di indagare sulle loro pratiche di sicurezza. Nota anche che è meglio scoprire i problemi prima che tardi. Sono sicuro che, se necessario, potresti tornare indietro da quel sistema, mentre in un anno un problema che ha portato alla perdita di tutti i dati sui salari memorizzati potrebbe non esserlo.

È causa di gravi sospetti e probabilmente di altri problemi, tuttavia:

Se il sistema fosse, in questo caso, vulnerabile a SQL injection, il tuo aggiornamento sarebbe fallito:

UPDATE users SET first_name = '?' WHERE user_id = ?;
UPDATE users SET first_name = 'O'Henry' WHERE user_id = 1; //substituting without escaping

Come puoi vedere il parser SQL vede first_name = 'O' ma dal momento che Henry non corrisponde a una parola di controllo genererà un errore.