Che tipo di attacco è l'iniezione SQL? Sono confuso perché questo tipo di attacco è fatto attraverso il lato client. Tuttavia, il target degli hacker è un database che è "dietro" un server. La maggior parte degli attacchi da parte di OWASP Top 10 attacchi del 2017 sono lato server, ma gli attacchi vengono eseguiti attraverso il lato client. Qualcuno può spiegare perché sono classificati come server-side?
Il database è memorizzato sul server. Ciò significa che il server è la cosa che viene direttamente danneggiata durante l'iniezione SQL riuscita (potrebbero esserci effetti secondari sul client, ma il server viene danneggiato prima ).
Pertanto, SQL injection è innanzitutto un attacco dal lato server.
SQL injection è un attacco lato server perché modifica il ritorno della query SQL nel codice back-end per intenzioni malevole.
Alcune informazioni aggiuntive: SOLO La convalida del lato client non è sufficiente. È DEVE avere anche la convalida dell'input lato server. Perché l'attaccante può catturare il pacchetto prima se viene inviato al server MA dopo che è stato inviato dal browser (dopo la convalida) e modificare di nuovo il pacchetto e renderlo dannoso.
Gli attacchi dal lato client consistono principalmente in Javacript, XSS, CSRF perché manipolano o ingannano l'HTML / JavaScript.
Un modo semplice per pensarci è considerare dove potrebbe avvenire una soluzione pulita. Se il client viene riparato, un utente malintenzionato può modificare il proprio client per consentire loro di effettuare l'attacco SQL injection. Se il server viene riparato, l'autore dell'attacco non può più sfruttare il problema.
Per un esempio opposto di un bug del client: immagina che il server abbia una funzione in cui ogni utente può avere un testo "biografia" arbitrario modificabile dall'utente associato al suo profilo e ci sono numerosi luoghi pubblici nell'interfaccia utente web e altri client (come app per dispositivi mobili o desktop che non sono necessariamente basate su HTML) che questo testo è mostrato. Immagina che uno dei tanti clienti tratti casualmente questo testo biografico come HTML e consenta attacchi XSS. Se si tenta di applicare la patch sul server disabilitando l'HTML nel testo della biografia, gli utenti non possono più parlare di HTML nelle loro biografie (che in precedenza funzionavano bene in ogni altro client). La vulnerabilità è in un client in particolare, e se quel client fosse stato risolto, il problema sarebbe stato risolto in modo pulito e non sarebbe più sfruttabile. (Se il server sa a quale client sta parlando, il server potrebbe aggirare il bug del client codificando la biografia in HTML prima di darlo al client, ma questa non è esattamente una soluzione pulita. Non si può mai fare una misura di stopgap, solo dire che questo tipo di work-around non influisce sulla questione se si tratti di un problema di server o client.)
Leggi altre domande sui tag sql-injection