Esistono numerosi strumenti e tecniche utilizzati da questi gruppi e, anche se non stiamo cercando di darti un manuale per farlo da soli, è utile capire cosa sta succedendo. Due degli attacchi che si sentono costantemente su di loro utilizzando sono "(Distributed) Denial of Service" (DDoS) e "SQL Injections" (SQLI). Ecco come funzionano.
Immagine di xkcd
Denial of Service Attack
Che cos'è?
Un "denial of service" (talvolta chiamato attacco "distributed denial of service" o DDoS) si verifica quando un sistema, in questo caso un server Web, riceve così tante richieste contemporaneamente che le risorse del server sono sovraccaricate, il sistema si blocca semplicemente e si spegne. L'obiettivo e il risultato di un attacco DDoS di successo sono i siti Web sul server di destinazione non disponibili per le richieste di traffico legittime.
Come funziona?
La logistica di un attacco DDoS può essere meglio spiegata da un esempio.
Immagina che un milione di persone (gli attaccanti) si uniscano con l'obiettivo di ostacolare gli affari della compagnia X abbattendo il loro call center. Gli aggressori si coordinano in modo che martedì alle 9:00 chiameranno tutti il numero di telefono della compagnia X. Molto probabilmente, il sistema telefonico della compagnia X non sarà in grado di gestire un milione di chiamate contemporaneamente così tutte le linee in arrivo saranno bloccate dagli aggressori. Il risultato è che le chiamate telefoniche legittime (ad esempio quelle che non sono gli attaccanti) non arrivano perché il sistema telefonico è impegnato a gestire le chiamate degli aggressori. Quindi, in sostanza, l'azienda X sta potenzialmente perdendo business a causa delle legittime richieste che non possono essere soddisfatte.
Un attacco DDoS su un server Web funziona esattamente nello stesso modo. Poiché non esiste praticamente alcun modo per sapere quale traffico proviene da richieste legittime e malintenzionati finché il server Web non elabora la richiesta, questo tipo di attacco è in genere molto efficace.
Esecuzione dell'attacco
A causa della natura di "forza bruta" di un attacco DDoS, è necessario disporre di un numero elevato di computer tutti coordinati per attaccare allo stesso tempo. Rivedendo il nostro esempio di call center, questo richiederebbe a tutti gli aggressori di sapere entrambi di chiamare alle 9:00 e di chiamare in quel momento. Mentre questo principio funzionerà sicuramente quando si tratta di attaccare un server web, diventa molto più semplice quando vengono utilizzati i computer zombie, invece dei computer effettivamente equipaggiati.
Come probabilmente saprai, ci sono molte varianti di malware e trojan che, una volta sul tuo sistema, giacciono dormienti e occasionalmente "telefonano a casa" per le istruzioni. Una di queste istruzioni potrebbe, ad esempio, essere quella di inviare richieste ripetute al server Web di Company X alle 9 del mattino. Quindi, con un singolo aggiornamento alla posizione home del rispettivo malware, un singolo utente malintenzionato può coordinare istantaneamente centinaia di migliaia di computer compromessi per eseguire un massiccio attacco DDoS.
La bellezza dell'utilizzo di computer zombi non è solo nella sua efficacia, ma anche nel suo anonimato in quanto l'attaccante non deve in realtà utilizzare il proprio computer per eseguire l'attacco.
SQL Injection Attack
Che cos'è?
Un attacco "SQL injection" (SQLI) è un exploit che sfrutta le scarse tecniche di sviluppo Web e, in genere, combinato con una sicurezza del database difettosa. Il risultato di un attacco riuscito può variare dalla rappresentazione di un account utente a una completa compromissione del rispettivo database o server. A differenza di un attacco DDoS, un attacco SQLI è completamente e facilmente prevenibile se un'applicazione Web viene programmata in modo appropriato.
Esecuzione dell'attacco
Ogni volta che accedi a un sito web e inserisci il tuo nome utente e la password, per testare le tue credenziali l'applicazione web può eseguire una query come la seguente:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Nota: i valori stringa in una query SQL devono essere racchiusi tra virgolette singole, motivo per cui vengono visualizzati attorno ai valori immessi dall'utente.
Pertanto, la combinazione del nome utente immesso (myuser) e della password (bypass) deve corrispondere a una voce nella tabella Users affinché venga restituito un ID utente. Se non vi è alcuna corrispondenza, nessun ID utente viene restituito in modo che le credenziali di accesso non siano valide. Mentre una particolare implementazione può differire, la meccanica è piuttosto standard.
Quindi ora esaminiamo una query di autenticazione del modello che possiamo sostituire i valori immessi dall'utente nel modulo Web:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
A prima vista, questo può sembrare un passaggio semplice e logico per convalidare facilmente gli utenti, tuttavia se una semplice sostituzione dei valori immessi dall'utente viene eseguita su questo modello, è suscettibile di un attacco SQLI.
Ad esempio, supponiamo che "myuser" - "sia inserito nel campo del nome utente e" wrongpass "sia inserito nella password. Usando la semplice sostituzione nella nostra query del modello, otterremmo questo:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Una chiave per questa affermazione è l'inclusione dei due trattini
(--)
. Questo è il token di commento iniziale per le istruzioni SQL, quindi tutto ciò che appare dopo i due trattini (incluso) verrà ignorato. In sostanza, la query precedente viene eseguita dal database come:
SELECT UserID FROM Users WHERE UserName='myuser'
L'omissione clamorosa qui è la mancanza del controllo della password.Includendo i due trattini come parte del campo utente, abbiamo completamente aggirato la condizione di controllo della password e siamo stati in grado di accedere come "myuser" senza conoscere la rispettiva password. Questo atto di manipolare la query per produrre risultati non previsti è un attacco di SQL injection.
Che danno può essere fatto?
Un attacco SQL injection è causato dalla codifica dell'applicazione negligente e irresponsabile ed è completamente prevenibile (che copriremo in un momento), tuttavia l'entità del danno che può essere fatto dipende dalla configurazione del database. Affinché un'applicazione web possa comunicare con il database di back-end, l'applicazione deve fornire un accesso al database (nota, questo è diverso da un accesso utente al sito Web stesso). A seconda delle autorizzazioni richieste dall'applicazione Web, questo rispettivo account di database può richiedere qualsiasi tipo di autorizzazione di lettura / scrittura nelle tabelle esistenti solo per l'accesso completo al database. Se questo non è chiaro ora, alcuni esempi dovrebbero aiutare a fornire una certa chiarezza.
In base all'esempio precedente, puoi vederlo inserendo, ad esempio,
'youruser'--', 'admin'--'
o qualsiasi altro nome utente, possiamo accedere istantaneamente al sito come tale utente senza conoscere la password. Una volta che siamo nel sistema non sappiamo che non siamo in realtà quell'utente, quindi abbiamo pieno accesso al rispettivo account. Le autorizzazioni del database non forniranno una rete di sicurezza per questo perché, in genere, un sito Web deve disporre almeno dell'accesso in lettura / scrittura al rispettivo database.
Ora supponiamo che il sito web abbia il pieno controllo del rispettivo database che dà la possibilità di cancellare record, aggiungere / rimuovere tabelle, aggiungere nuovi account di sicurezza, ecc. È importante notare che alcune applicazioni web potrebbero aver bisogno di questo tipo di permesso non è automaticamente una cosa cattiva che è garantito il pieno controllo.
Quindi, per illustrare il danno che può essere fatto in questa situazione, useremo l'esempio fornito nel fumetto qui sopra inserendo quanto segue nel campo del nome utente:
'Robert'; DROP TABLE Users;--'.
Dopo la semplice sostituzione la query di autenticazione diventa:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Nota: il punto e virgola in una query SQL viene utilizzato per indicare la fine di una particolare istruzione e l'inizio di una nuova istruzione.
Che viene eseguito dal database come:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Users
Quindi, proprio così, abbiamo usato un attacco SQLI per cancellare l'intera tabella Utenti.
Naturalmente, si può fare molto di peggio poiché, a seconda delle autorizzazioni SQL consentite, l'utente malintenzionato può modificare i valori, eseguire il dump delle tabelle (o l'intero database stesso) in un file di testo, creare nuovi account di accesso o addirittura dirottare l'intera installazione del database.
Prevenire un attacco di SQL injection
Come accennato più volte in precedenza, un attacco di SQL injection è facilmente prevenibile. Una delle regole cardine dello sviluppo web è che non ci si fida mai ciecamente dell'input dell'utente come abbiamo fatto quando eseguivamo una semplice sostituzione nella nostra query modello sopra.
Un attacco SQLI è facilmente vanificato da ciò che viene chiamato sanitizzare (o sfuggire) i tuoi input. Il processo di sanitizzazione è in realtà piuttosto banale in quanto tutto ciò che essenzialmente fa è gestire qualsiasi carattere inline single quote (') in maniera tale che non possano essere usati per terminare prematuramente una stringa all'interno di un'istruzione SQL.
Ad esempio, se si desidera cercare "O'neil" in un database, non è possibile utilizzare la semplice sostituzione poiché la virgoletta singola dopo O causerebbe la fine prematura della stringa. Invece si sanifica usando il carattere di escape del rispettivo database. Supponiamo che il carattere di escape per una singola virgoletta in linea sia la pre-introduzione di ogni citazione con un simbolo. Quindi "O'neal" sarebbe stato sanificato come "O 'neil".
Questo semplice atto di risanamento impedisce praticamente un attacco SQLI. Per illustrare, rivisitiamo i nostri esempi precedenti e vediamo le query risultanti quando l'input dell'utente è sterilizzato.
myuser'--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Poiché la virgoletta singola dopo che myuser è stato sfuggito (ovvero è considerato parte del valore di destinazione), il database cercherà letteralmente lo UserName di
'myuser'--'.
Inoltre, poiché i trattini sono inclusi nel valore stringa e non nell'istruzione SQL stessa, verranno considerati parte del valore obiettivo anziché essere interpretati come commento SQL.
Robert'; DROP TABLE Users;--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Eseguendo semplicemente la citazione singola dopo Robert, sia il punto e virgola che i trattini sono contenuti nella stringa di ricerca UserName, quindi il database cercherà letteralmente
'Robert'; DROP TABLE Users;--'
invece di eseguire la cancellazione della tabella.
In sintesi
Mentre gli attacchi web si evolvono e diventano più sofisticati o si concentrano su un diverso punto di ingresso, è importante ricordare di proteggere da attacchi veri e provati che sono stati l'ispirazione di diversi "strumenti hacker" liberamente disponibili progettati per sfruttarli.
Alcuni tipi di attacchi, come DDoS, non possono essere facilmente evitati mentre altri, come SQLI, possono. Tuttavia, il danno che può essere causato da questi tipi di attacchi può variare da qualsiasi inconveniente a catastrofico a seconda delle precauzioni prese.
![Divertiti a digitare come un hacker con Hacker Typer [Geek Fun]](https://i.technology-news-hub.com/images/blog/have-fun-typing-like-a-hacker-with-hacker-typer-geek-fun-1-p.webp "Divertiti a digitare come un hacker con Hacker Typer [Geek Fun]")
