Delle rivelazioni pubbliche che ho visto da siti compromessi di recente, sembra comune che solo il database sia trapelato, piuttosto che il codice dell'applicazione, o piuttosto che un'acquisizione completa. Questo perché esiste una classe di attacchi comuni che sono limitati all'accesso al database di sola lettura?
I primi che vengono in mente sono:
È inoltre del tutto possibile che gli attaccanti nelle fughe di cui parli abbiano privilegi o privilegi almeno superiori a quelli di sola lettura, ma scelgono di non usarli. Oppure li hanno usati ma quell'uso non è stato ancora rilevato. O che hanno il codice completo dell'applicazione ma hanno scelto di non perderlo.
Un pensiero interessante che ho appena scritto scrivendo sulla prevenzione 1. riducendo la superficie di attacco è quello di avere un account utente di database separato che ha accesso solo alla tabella delle credenziali e il tuo normale utente di sola lettura non ha accesso a questo tavolo. In questo modo, solo un'iniezione SQL nel modulo di accesso può compromettere gli hash delle password. Qualsiasi iniezione SQL in un'altra parte dell'applicazione Web non può vedere gli hash delle password (o qualsiasi altro dato sensibile che possiedi).
Il database è la miniera d'oro, ecco perché filtrare i dati significa tutte le cose cattive. Il codice sorgente dell'applicazione è importante in alcuni casi, ma se si guarda all'architettura delle applicazioni moderne, la maggior parte dei dati proviene dal database back-end. Credenziali, informazioni personali, numeri di carte di credito, dati finanziari e aziendali, quasi tutto ciò che si desidera proteggere è nel database.
Compromettere il server (come ottenere la shell) è importante solo in caso di attacchi bot in modo che la rete bot sia espansa. Gli attacchi mirati sono sempre per i dati. Pertanto, compromettere il database significa raggiungere l'obiettivo.
Per quanto riguarda la cosa "attacchi da comando", la maggior parte dei siti Web viene compromessa tramite l'iniezione SQL che esegue direttamente query di attacco sul database. Il database di sola lettura è il minimo che si ottiene in SQL injection. SQLi può comportare un completo compromesso della macchina anche caricando il codice shell tramite la direttiva "INTO DUMPFILE" e questi chiamano la shell attraverso l'applicazione web, risultando in una shell interattiva completa attraverso il browser.
Quindi la perdita di dati per la maggior parte del tempo raggiunge l'obiettivo, ecco perché gli aggressori si fermano qui. Altrimenti, SQL injection offre anche molte altre modalità di attacco.
Suppongo che se troveranno un'iniezione SQL e l'utente che il sito Web utilizza per interrogare il database ha solo accesso in lettura, il risultato sarebbe in effetti che egli può solo eseguire un attacco di input sql di sola lettura. Ma non penso che ci sia una classe specifica per quel tipo di attacchi. In generale, ci limitiamo ad anteporre nome di attacco
di sola letturaSe il database è l'unica parte compromessa dell'applicazione web, è quasi sempre una SQL Injection , che abusa di una funzione dell'applicazione (ad esempio un modulo di ricerca) per estrarre dati arbitrari dal sottostante banca dati.
Una perdita di database potrebbe anche essere causata da un attacco interno , eseguito da un dipendente con sufficienti privilegi per accedere al database.
È possibile trovare dump di database parziali e completi tramite Google Hacking , che utilizza i motori di ricerca per scoprire i file sensibili che sono stati indicizzati.
Infine, includerei gli errori dell'applicazione che potrebbero rivelare dati dal database se le eccezioni non vengono gestite correttamente.