In breve: Forse
Da un lato sì, questo è un rischio molto reale . Con molte installazioni di applicazioni ordinarie e distribuzioni di database, questa vulnerabilità ti permetterà di accedere ai dati.
D'altra parte, no, un utente malintenzionato può essere bloccato anche in questa fase . Esistono numerose tecniche per mitigare questo rischio. Ad esempio:
-
Privilegio limitato sul sistema operativo . I comandi arbitrari che l'attaccante sta eseguendo sul server delle applicazioni devono essere eseguiti con le credenziali di un particolare utente; se l'account utente è stato configurato in base al principio del privilegio minimo , l'account utente potrebbe non disporre dell'autorizzazione per l'esecuzione quei comandi arbitrari. Idealmente, l'account utente avrà il permesso di eseguire l'applicazione ma non fare assolutamente nient'altro.
Nota: SELinux è una tecnica potente per limitare ulteriormente l'accesso alle risorse del sistema operativo.
-
Accesso limitato al DB . Anche se un utente malintenzionato scopre le credenziali del database, potrebbe non essere molto utile. Il database può essere configurato in modo che tali credenziali siano valide solo per tale applicazione; quindi non possono essere utilizzati per connettersi al database tramite altri strumenti. Oppure, il database può essere configurato in modo tale che queste credenziali siano valide solo da questo unico indirizzo client; quindi tutte le connessioni db dell'utente malintenzionato devono essere sottoposte a tunnel attraverso il server del database, anziché dal proprio sistema.
-
Non ci sono credenziali del DB memorizzate . Un'applicazione può essere progettata in modo che l'utente inserisca le proprie credenziali all'accesso, ad esempio, e queste siano utilizzate per accedere al DB. In questa situazione, un utente malintenzionato sul server delle applicazioni non è in grado di connettersi al DB, indipendentemente dal livello di controllo a livello di sistema operativo.
-
Le credenziali del DB sono archiviate altrove . Un'applicazione può essere configurata in modo che recuperi le credenziali del DB da un servizio separato in fase di runtime; questo servizio separato potrebbe non consentire le connessioni tranne che dall'applicazione stessa.
Nota ulteriore: queste tecniche non sono esclusive, quindi combinarle potrebbe essere un modo efficace per limitare l'accesso di un attaccante. Tuttavia, ognuna di queste tecniche richiede una sofisticata configurazione non predefinita, e una distribuzione ingenua è probabile che manchi ogni singolo.